前言

大家好，在下蠻咕咕（我是“鴿”王），好久不見啊。

最近我司已經(jīng)放假過年了，在家里就不免會(huì)多逛一些“稀奇古怪”的網(wǎng)站，通過阮一峰的每周新聞，發(fā)現(xiàn)了一篇比較不錯(cuò)的英文文章。

里面的大部分觀點(diǎn)我都比較認(rèn)同，在這里做了一個(gè)比較接地氣的翻譯，分享給大家。

正文

在軟件產(chǎn)業(yè)工作六年后，我對軟件行業(yè)的一些想法發(fā)生了改變。

以下這些觀點(diǎn)是我以前內(nèi)心比較矛盾，但是現(xiàn)在堅(jiān)信的事情：

當(dāng)你工作在一個(gè)開發(fā)人員眾多且擁有不同開發(fā)水平的小組中，使用強(qiáng)類型語言顯然更為合適。

站會(huì)（敏捷開發(fā)中的站立會(huì)議）對于跟進(jìn)團(tuán)隊(duì)中新手的進(jìn)度來說，非常有用。

敏捷開發(fā)中的迭代復(fù)盤會(huì)，是有其意義的，前提是為了糾正過往迭代的失誤（比如發(fā)現(xiàn)一些“這樣做真蠢！”的故事），而不是在一些‘敏捷大師’的教條下，浪費(fèi)大家的時(shí)間。

軟件架構(gòu)比任何東西都要重要。一個(gè)好的抽象，就算是實(shí)現(xiàn)的比較拉胯，對于代碼來說傷害非常小。但是如果沒有好的抽象，就算實(shí)現(xiàn)的再漂亮，那也是在堆屎，對代碼傷害極大。

Java并不是那么爛（譯者注：看來大佬對Java怨念頗深）。

炫技的代碼通常并不是好代碼，一個(gè)清晰明了的代碼比任何代碼都好。

你永遠(yuǎn)想象不到垃圾代碼能寫的多么奇葩。

所謂的“最佳實(shí)踐（Best Practise）”通常是有特定背景的，不具有廣泛的適用性。盲目地追隨他們會(huì)使你成為一個(gè)蠢貨。

在不需要的時(shí)候強(qiáng)行去設(shè)計(jì)高度可伸縮的系統(tǒng)，會(huì)讓你成為一個(gè)糟糕的工程師。

代碼靜態(tài)分析是很有用的。

DRY（Don't repeat yourself）不要造輪子：通常是用于避免一個(gè)特定的問題，而不是作為一個(gè)終極目的，所以不要盲目追求沒有重復(fù)。

通常情況下，RDBMS（關(guān)系數(shù)據(jù)庫）優(yōu)于 NoSql （特指非關(guān)系數(shù)據(jù)庫）。

函數(shù)式編程僅僅是另一種編程手法，而不是靈丹妙藥。

以下是我這一路以來了解到并認(rèn)可的觀點(diǎn)：

第一，YAGNI（非必要時(shí)不加入新代碼）, 其次， SOLID（面向?qū)ο笤O(shè)計(jì)）, 第三， DRY（不要重復(fù)造輪子），按照這個(gè)優(yōu)先級去寫代碼。

鉛筆和紙是最好的編程工具，而且經(jīng)常會(huì)用到。

用純粹性換取實(shí)用性通常是個(gè)不錯(cuò)的選擇。

往項(xiàng)目中增加更多的技術(shù)框架，通常不是個(gè)好選擇。

直接與客戶交談總是能在更短的時(shí)間內(nèi)，通過更高的準(zhǔn)確性來暴露更多的軟件問題。

“可伸縮性”這個(gè)詞在軟件工程師的頭腦中有一種神秘而令人震驚的力量。僅僅這一句話就能把他們搞的心力憔悴。

盡管被稱外人稱為“工程師”，但大多數(shù)開發(fā)人員的決定都是根據(jù)個(gè)人喜好或者“看心情”，沒有數(shù)據(jù)的支持。

有90%，甚至93%的項(xiàng)目經(jīng)理明天可能就會(huì)消失，并且并不會(huì)造成影響，甚至?xí)嵘?。（譯者注：這個(gè)原文意思不知道我理解的對不對）

在完成了100多次面試之后，我依然不知道如何讓面試變得更好，。（譯者注：面試很難真正看清一個(gè)人的開發(fā)水平）

以下是這么多年來我依然不變的觀點(diǎn)：

過分強(qiáng)調(diào)代碼風(fēng)格、規(guī)則或其他細(xì)節(jié)的人是極端分子，毫無意義。

代碼覆蓋率對于提升代碼質(zhì)量沒有絲毫幫助。

在大多數(shù)情況下，大應(yīng)用（Monoliths）的效果是很好的，并不一定要細(xì)分成非常復(fù)雜的微服務(wù)。

無腦信奉TDD（測試驅(qū)動(dòng)開發(fā)）的人是最糟糕的，他們脆弱的小腦袋無法處理不同工作流程的存在。

在10年后，讓我們再看看，這些觀點(diǎn)是否會(huì)發(fā)生變化。

Software development topics I've changed my mind on after 6 years in the industry.

Things I now believe, which past me would've squabbled with:

Typed languages are better when you're working on a team of people with various experience levels
Standups are actually useful for keeping an eye on the newbies.
Sprint retrospectives have their place so long as they're for actual course correction (i.e. "holy shit, that went poorly!") and not some god awful ?'agile' / 'scum master' driven waste of everyone's time
Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.
Java isn't that terrible of a language.
Clever code isn't usually good code. Clarity trumps all other concerns.
Bad code can be written in any paradigm
So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot
Designing scalable systems when you don't need to makes you a bad engineer.
Static analysis is useful DRY is about avoiding a specific problem, not an end goal unto itself. In general, RDBMS > NoSql Functional programming is another tool, not a panacea.

Opinions I've picked up along the way

YAGNI, SOLID, DRY. In that order.
Pencil and paper are the best programming tools and vastly under used
Trading purity in exchange for practicality is usually a good call
Adding more technology is rarely a good call
Talking directly to the customer always reveals more about the problem, in less time, and with higher accuracy
The word "scalable" has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word
Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers
90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

Old opinions unchanged:

People who stress over code style, linting rules, or other minutia are insane weirdos
Code coverage has absolutely nothing to do with code quality
Monoliths are pretty good in most circumstances
TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.

We'll see which of these have flipped or changed at year 10.