【譯文】工做六年後，我對軟件開發的認知轉變

前言

你們好，在下蠻咕咕（我是「鴿」王），很久不見啊。

最近我司已經放假過年了，在家裏就難免會多逛一些「稀奇古怪」的網站，經過阮一峯的每週新聞，發現了一篇比較不錯的英文文章。

裏面的大部分觀點我都比較認同，在這裏作了一個比較接地氣的翻譯，分享給你們。

正文

在軟件產業工做六年後，我對軟件行業的一些想法發生了改變。

如下這些觀點是我之前心裏比較矛盾，可是如今堅信的事情：

1. 當你工做在一個開發人員衆多且擁有不一樣開發水平的小組中，使用強類型語言顯然更爲合適。

2. 站會（敏捷開發中的站立會議）對於跟進團隊中新手的進度來講，很是有用。

3. 敏捷開發中的迭代覆盤會，是有其意義的，前提是爲了糾正過往迭代的失誤（好比發現一些「這樣作真蠢！」的故事），而不是在一些‘敏捷大師’的教條下，浪費你們的時間。

4. 軟件架構比任何東西都要重要。一個好的抽象，就算是實現的比較拉胯，對於代碼來講傷害很是小。可是若是沒有好的抽象，就算實現的再漂亮，那也是在堆屎，對代碼傷害極大。

5. Java並非那麼爛（譯者注：看來大佬對Java怨念頗深）。

6. 炫技的代碼一般並非好代碼，一個清晰明瞭的代碼比任何代碼都好。

7. 你永遠想象不到垃圾代碼能寫的多麼奇葩。

8. 所謂的「最佳實踐（Best Practise）」一般是有特定背景的，不具備普遍的適用性。盲目地追隨他們會使你成爲一個蠢貨。

9. 在不須要的時候強行去設計高度可伸縮的系統，會讓你成爲一個糟糕的工程師。

10. 代碼靜態分析是頗有用的。

11. DRY（Don't repeat yourself）不要造輪子：一般是用於避免一個特定的問題，而不是做爲一個終極目的，因此不要盲目追求沒有重複。

12. 一般狀況下，RDBMS（關係數據庫）優於 NoSql （特指非關係數據庫）。

13. 函數式編程僅僅是另外一種編程手法，而不是靈丹妙藥。

如下是我這一路以來了解到並承認的觀點：

1. 第一，YAGNI（非必要時不加入新代碼）, 其次， SOLID（面向對象設計）, 第三， DRY（不要重複造輪子），按照這個優先級去寫代碼。

2. 鉛筆和紙是最好的編程工具，並且常常會用到。

3. 用純粹性換取實用性一般是個不錯的選擇。

4. 往項目中增長更多的技術框架，一般不是個好選擇。

5. 直接與客戶交談老是能在更短的時間內，經過更高的準確性來暴露更多的軟件問題。

6. 「可伸縮性」這個詞在軟件工程師的頭腦中有一種神祕而使人震驚的力量。僅僅這一句話就能把他們搞的心力憔悴。

7. 儘管被稱外人稱爲「工程師」，但大多數開發人員的決定都是根據我的喜愛或者「看心情」，沒有數據的支持。

8. 有90%，甚至93%的項目經理明天可能就會消失，而且並不會形成影響，甚至會提高效率。（譯者注：這個原文意思不知道我理解的對不對）

9. 在完成了100屢次面試以後，我依然不知道如何讓面試變得更好，。（譯者注：面試很難真正看清一我的的開發水平）

如下是這麼多年來我依然不變的觀點：

1. 過度強調代碼風格、規則或其餘細節的人是極端分子，毫無心義。

2. 代碼覆蓋率對於提高代碼質量沒有絲毫幫助。

3. 在大多數狀況下，大應用（Monoliths）的效果是很好的，並不必定要細分紅很是複雜的微服務。

4. 無腦信奉TDD（測試驅動開發）的人是最糟糕的，他們脆弱的小腦殼沒法處理不一樣工做流程的存在。

5. 在10年後，讓咱們再看看，這些觀點是否會發生變化。

英文原文

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.

小尾巴

以前也翻譯過一篇比較經典的外文文章，感興趣的朋友能夠回看下以前的文章：

通俗易懂的生產環境Web應用架構介紹

參考

https://chriskiehl.com/article/thoughts-after-6-years

關注我

我是一名奮鬥在一線的互聯網後端開發工程師。

主要關注後端開發，數據安全，邊緣計算等方向，歡迎交流。

各大平臺都能找到我

• 微信公衆號：後端技術漫談
• Github：@qqxx6661
• CSDN：@蠻三刀把刀
• 知乎：@後端技術漫談
• 掘金：@蠻三刀把刀
• 騰訊雲+社區：@後端技術漫談
• 博客園：@後端技術漫談
• BiliBili：@蠻三刀把刀

原創文章主要內容

• 後端開發實戰
• 後端技術面試
• 算法題解/數據結構/設計模式
• 生活趣聞

我的公衆號：後端技術漫談

若是文章對你有幫助，求各位大佬點贊支持一下，你的點贊和在看是我更新的動力~