工作六年后，對軟件開發的一些新觀點
一個人的智力是否屬于上乘，要看腦子里能否同時容納兩種相反的思想而無礙其處世行事;今天 pshu 翻譯了一位有 6 年工作經驗的軟件工程師的觀點。希望這些立場鮮明的觀點可以成為你提高大腦容量的素材。
原文地址 https://chriskiehl.com/article/thoughts-after-6-years 《Software development topics I've changed my mind on after 6 years in the industry》
以前懷疑但現在認同的觀點
當你需要和不同經驗的開發人員一起合作時，使用強類型語言更適合一些(譯者注：如Typescript)
站立會議(晨會的一種形式)對幫助新人很有用
回顧會(scrum 開發模式中用來總結前一次迭代中得失的會議)還是有其存在意義的，因為它能幫忙我們糾正開發過程中的錯誤;它并不是敏捷開發中 scrum master 想出來浪費時間多余的會議。
軟件架構很重要。一個好的抽象配上一個糟糕的實現不會對代碼造成多嚴重的影響;但是一個錯誤的抽象和分層遺漏，就導致代碼很容易變爛。
Java 并不垃圾。
投機取巧、奇技淫巧的代碼不是好代碼;代碼的可讀性最重要。
不要迷信編程范式，任何編程范式中都可能寫出爛代碼。
所謂的“最佳實踐”都是有具體場景的，并不是萬金油。如果盲目地追求“最佳實踐”，那很有可能成為最佳笨蛋。
如果沒有必要，合格的工程師是不會主動去設計一個可擴展的系統。
代碼的靜態分析很有用(譯者注：比如 lint，但是糾結具體的規則，參見后面“始終認同的觀點”的第一條)
DRY(Don’t Repeat yourself )只是用來規避一類特殊的問題，而不是一個目標。
一般情況下，關系型數據庫(RDBMS)比非關系型數據庫(NoSQL)好。
函數式編程只是一個工具，不是靈丹妙藥
新學習到的觀點
編程時遵循的原則應該按照以下順序：YAGNI, SOLID, DRY。
YAGNI：You aren't gonna need it, 不要去寫你目前不需要的功能，大部分預測未來是無效的;
SOLID：面向對象設計中的 5 個原則：
- Single-responsibility principle單一職責原則
- Open–closed principle 對擴展開放對修改掉封閉原則，也簡稱開閉原則
- Liskov substitution principle 李氏替換原則
- Interface segregation principle 接口隔離原則
- Dependency inversion principle 依賴翻轉原則
DRY：Don't repeat yourself, 只做一次原則
如果你這三個縮寫都懂，那么可以嘗試用自己的想法和這個觀點PK下，如果這些名詞都不懂，最好空杯心態先接受學習下。
紙和筆仍舊是最好的編程工具，但他們仍未被大量使用
在純粹主義和實用主義之間做一個折中，通常都會是個好主意
增加更多的技術棧并不是一個好主意
直接和用戶溝通往往能花更少的時間并且更加準確地了解問題。
“可擴展性”這個詞在程序員心中是種神秘的迷信;只要提了這個詞就會驅使他們進入癲狂的瘋狂狀態;做再殘酷的事情好像都是合理的。
盡管戴著“工程師”這個高帽，但是他們大部分工程師決策都是盲目地使用現有的技術框架或者編程模式，不做任何技術分析和調研。
90%甚至 93%的項目經理在項目中其實可有可無;即使明天他們突然消失了，也不會對項目有任何負面影響，甚至可能還能提高效率。
在進行了 100 多場面試之后，我發現面試是完全沒有用的;但我也不知道如何更好地面試。
始終認同的觀點
糾結于代碼風格，lint規則和其他瑣事的人都是瘋子
代碼覆蓋率和代碼質量之間沒有關系
單體倉庫在大多數情況下更好。
TDD純粹主義者最菜。他們脆弱的小腦袋里面容不下其他現存的工作方式。
在工作10年后，我們再看看這些看法有什么改變。
翻譯完。
