怎么提高代碼質量？-來自Google的研發經驗總結(2)

除此之外，嚴格的code review不僅能保證代碼的質量，還能形成良好的技術氛圍。
4. 開發未動文檔先行
編寫技術文檔對大部分工程師來說都是挺反感的事情。一般來講在開發某個系統或者重要模塊或者功能之前需要先寫技術文檔，然后發送給同組或者相關同事審查，在審查沒有問題的情況下再開發，這樣能夠事先達成共識，開發出來的東西不至于走樣，而且當開發完成之后進行code review的階段，代碼審查者通過閱讀開發文檔也可以快速的理解代碼．
除此之外，文檔對于團隊和公司來講都是重要的財富，對于新人加入公司熟悉代碼，產品，對于任務的交接等等都很有幫助，而且作為一個規范化的技術團隊，技術文檔是一種摒棄作坊式開發和個人英雄主義的有效方法，是保證團隊有效協作的途徑．
不過，有很多工程師提出說不會寫技術文檔，不知道寫什么，希望給一個模板或者目錄．我之前曾經想過是否可以給出一個固定的模板，但最后還是放棄了，比較難，難點在于，每個項目側重點都不一樣不容易總結，如果硬要給出一個很寬泛的目錄，不具有指導性也沒有意義．大體上來講，文檔的內容主要是將做的東西講清楚，包括出問題背景，解決了什么問題，外部怎么用或調用，內部如何實現，大的架構，關鍵功能和算法等，以及一些非功能性的考慮。
5. 持續重構，重構，重構
個人比較反對平時不注重代碼質量，堆砌爛代碼，實在維護不了了就大刀闊斧的重構甚至重寫。有時候項目代碼太多了，重構很難做到徹底，最后又搞出來一個四不像的怪物，更麻煩了！
優秀的代碼或架構不是一開始就能完全設計好的，就像優秀的公司或產品也都是迭代出來的一樣的，我們無法100%遇見未來的需求，也沒有足夠的精力，時間，資源為遙遠的未來買單，所以隨著系統的演進，重構代碼也是不可避免的，雖然上面說了不支持大刀闊斧推到重來式的大重構，但持續的小重構還是比較推崇的，也是時刻保證代碼質量防止代碼腐化有效手段．簡單一句話就是不要等到問題堆得太多了再采取重構，要時刻有人對代碼整體負責任，平時沒事就改改代碼，而不要覺得重構代碼就是浪費時間，不務正業！
特別是一些業務開發團隊，有時候為了快速完成一個產品或者業務功能，只追求速度，到處hard code，在完全不考慮非功能性需求的情況下，堆砌一些爛代碼，這種情況還是比較常見的。不過沒關系，等有時間一定要記著重構，不然爛代碼越堆越多，總有一天會沒人能維護。
6. 項目與團隊”微服務化”
只有小項目是可以維護的，大項目是無法維護的．團隊人比較少的時候，十幾個人的樣子，代碼量也不多，不超過10萬行，怎么開發，怎么管理都沒問題，大家互相都了解彼此做的東西，代碼質量太差了，大不了重寫一遍．但如果是一個極其龐大的項目，幾十萬行代碼，幾十個開發維護，那基本上沒人能對代碼負責了．
所以當項目太大了之后，就需要對代碼和團隊進行拆分，模塊化，大團隊拆成幾個小團隊，大項目拆成幾個小項目，這樣每個團隊每個項目的代碼都不至于很多，也不至于出現代碼質量太差無法維護的情況，其實很多技術也都體現了這種思想，比如大到soa, 微服務，小到jar, .so等lib模塊開發，Class類的封裝，都是一種拆分的思想．
7. 重視代碼關注細節
以上其他的所有方法都是治標不治本，找到對的人用好對的人，打造優秀的技術文化，才是能一直卓越的根本。有很多工程師比較熱衷于學習架構，工具，框架層面的東西，見過很多工程師，還沒寫三五年代碼就轉做架構師，不寫代碼了，到處忽悠，很不好，互聯網信息如此透明，不同的人去做同一個項目，其實最后設計出來的架構,功能大約都差不多，最后大家都能把這個系統實現，但有些人做出來的系統，bug很多，性能很差，擴展性也不好，最多能叫個POC。
高手之間的競爭還是在于細節，一個算法夠不夠優化，數據存取的效率高不高，內存是否夠節省等等，這是累積起來決定了一個系統是不是夠優秀。
當然并不是說框架，工具，架構設計這些方面的學習不重要，關鍵是有深度，希望是實踐中鍛煉得來的，而不是到處看微信公眾號，博客得來的。
國內工程師普遍深度不夠，做幾年技術就轉管理或者純架構設計不寫代碼了，而國外不一樣，大齡碼農很多，所以國外的優秀開源項目比較多，而國內很少。

原文轉自：https://juejin.im/post/5c88ac2b5188257dda56c87e