寫高質量的代碼，不管你是程序員，架構師，這是最基本的技能。但是什麼是高質量代碼呢？有人說是clean code（整潔代碼），有人要有好的流程，有人說要有好的工具等等。我想說一下我自己的想法以及我通過自己經驗總結的10條建議。在列出這些建議之前，我想說一下為什麼要寫高質量代碼。
為什麼要寫高質量代碼？
- 大部分的工作都是維護工作，這是一個不爭的事實。不管你在大廠的，還是小廠，大部分的時候我們都是在維護一個項目，然後在上面做些修改，改bugs等等。如果是高質量並且可讀性強的代碼，會給我們維護帶來很大的方便。
- 我們花80%的時間都是在讀代碼而只有剩下20%時間寫代碼，這也是典型的二八原理，寫出來的代碼都是給人讀，而不僅是給機器讀。
- 質量不高的代碼（quick and dirty）的維護成本隨著時間的推移維護成本越來越高，越來越難維護，每次新加功能，都異常艱難，不能及時推出新功能，最終甚至導致公司倒閉。
4.如果代碼質量不高，閱讀困難，也會導致程序員不願意修改已有的代碼，而是自己寫的代碼代替。這樣導致代碼臃腫，重複。
5.代碼質量不高，直接影響產品的質量問題，客戶的滿意度下降。
那怎麼提高我們的代碼質量？
1.使用有意義的名字，這個在bob大叔在整潔代碼裡也非常強調這點，比如一個變量daysSinceCreation.一眼就能開出來這個是幹什麼的。如果是一個方法，直接看方法名，我就知道這個是幹什麼，比如setWindowTitle。下面有幾個例子，右邊是推薦的命名。
- validateForm --->getErrors,isValid,bindFromRequest
- getToken-->createToken,generateToken,fetchToken
- processLogin-->runPostRegistrationActions
2.減少註釋，儘量讓代碼自己展示自己的意圖。但是不是說註釋不重要，很多時候，註釋很重要，尤其是一些特殊邏輯。但是我們也知道維護註釋，是一種很困難事情，經常發生的是，代碼修改提交完成，但是註釋沒有改，導致很多的誤解。
3.重構，越早重構越好。當我們發現質量很差的代碼（比如 sonarlint檢測到不合規的代碼），我們要抽時間把他們修改了，而不是任其發展。大家可能知道那個“破窗理論”，如果不管不問，只會越來越糟。
4.單一職責，一個函數只做一件事，參數儘量少，2個最好，不能太多。這也是SOLID原則之一。
5.一定要寫測試。多年前，大家很重視TDD，但是TDD也有自身的問題。實際上，很少有公司應用嚴格的TDD過程。 與其說是測試優先開發，更具體地說，是任何新代碼都必須有新測試代碼。 換句話說，您永遠不會在沒有測試代碼的情況下產生一個新代碼。
6.接口優先，任何時候都從接口開始，然後才開始具體的實現。接口也是實現組件的可插入性（Pluggability）的關鍵。
7.迭代開發，這也是敏捷開發的核心。
8.獨立組件架構，獨立組件架構必須設計成其他組件的依賴性最小，這樣，每一個組件通過很小的改動，就可以很多別的地方使用。
9.優秀的工具（包括IDE和插件），比如說我們在開發Java時候，現在大部分都會用Intellij IDEA IDE 和插件sonarlint以及IDEA code style。
10.不要重新發明輪子，要用現成優秀的類庫，但是不要使用提供幾乎相同功能的多個庫。
有高質量可讀的代碼是把產品做好的前提。 難以理解的代碼不僅會嚇壞您的同事（以及您未來的自己），而且還會掩蓋錯誤並破壞整個團隊的開發進度，因為每次修改都需要兩倍甚至更多的時間。
