提高代碼內外部質量的22條經驗

總結的22條經驗以下： 

1. 代碼分爲外部質量和內部質量，好的產品不等於好的代碼（Good Software != Quality Code）。
2. 產品的冰山效應：產品經理以及用戶關注的部分只是冰山露在水面以上的部分，隱藏在下面的是看不見的更加龐大的部分，那就是咱們龐大的代碼。 
3. 拒絕 PPT 架構師，架構師應當寫代碼，哪怕這些代碼並不 Check-in 到最終的代碼庫中。一個好的設計不是在憑空產生的，而是通過不斷打磨、修改進而得到的。不存在一次設計，程序猿無腦堆砌代碼可以完成的好的程序。 
4. 編程的價值觀：溝通、簡單、靈活。
5. 代碼最重要的功能是傳遞程序員的設計和思路，其次纔是實現的功能。好的程序員應當寫出人類可以看懂的代碼，而不是機器能理解的代碼。
6. 效率不是犧牲清晰性的理由，不可以由於人主觀「認爲」的一些小伎倆，使用晦澀的代碼，企圖以此提高性能。應當依賴編譯器自己的優化，依賴工具對性能低下的點進行評測，進而進行鍼對性的優化。
7. 不要試圖死磕代碼加快速度，找個更加有效的算法可能更加有效。
8. 代碼要先作對，在弄快。先使其可靠，再讓其更快。先把代碼弄乾淨，再讓它變快。
9. Good code is not bad code。壞的代碼是能夠經過一些指標進行度量的。讓壞代碼的指標能夠被機器固化並時時檢查，確保代碼不會變得更糟。
10. 函數自己不是用來複用，這和不少「主流的」觀點不一樣。函數的存在的主要意義在於：劃分獨立職責，隱藏具體細節操做，使得代碼具備可讀性，應對擴展的變化，方便進行單元測試。順帶的，偶爾能夠用做複用。
11. 函數應當遵循：單一抽象層次原則、短小原則和單一職責原則。
12. 當發現一個函數具備如下特徵時，須要考慮抽取函數： 
    
    • 過長
    • 嵌套層數過深。
    • 天然分塊，須要使用註釋描述該程序塊
    • 判斷條件過於複雜
    • 函數的某些判斷分支不斷變化
    • 參數過於複雜
    • 邏輯重複
13. 局部變量應當用途單一
14. 新寫代碼邏輯，應當關注用戶場景和類職責劃分，不該當上來就考慮我要使用一個什麼模式。這樣勢必會致使過分設計。模式用做應對變化，當後續版本發生變化時，模式用做重構現有代碼。
15. 不斷重構，保持代碼簡潔。
16. 代碼是債務，一個程序員欠下的債務，老是要還的，雖然可能不是由本人還。維護老代碼的程序員又被稱做代碼考古工程師，常常在一大堆糟亂的代碼中挖掘最初的用戶需求，每每這些需求淹沒在無數的變動歷史中。維護老代碼是一個費時費力的過程。須要一些技巧減少修改老代碼的風險。
17. 程序員應當將整潔的代碼風格做爲一種習慣，時刻意識到整潔代碼的重要性並不斷地提升重構技巧。
18. 意圖導向編程能夠輔助思考，並生成易懂代碼。
19. 設計模式自己是用作應對變化的。若是在開發時就想着「我要用模式」，極可能會致使過分設計。在對代碼進行重構時，才應當考慮使用設計模式解決問題。
20. 函數名稱很重要。
21. 關於註釋：
    • 若是能用短小函數描述，則使用子函數替代註釋自己。
    • 確保註釋和代碼表達的意圖一致，不然就失去了註釋的意義。
    • 在重要的地方寫註釋，不要註釋滿天飛，簡單的重複代碼的功能是毫無心義的。要讓每一處註釋都有價值。不要過度註釋。
22. 關於什麼時候重寫代碼 
    
    • 開發團隊要預留20% 的時間用做保持對原有系統的重構。剩餘的時間用做開發新功能。
    • 只要有可能，對所要重構的部分進行遞增修改，讓用戶切身感覺到產品的改進，哪怕將工做時間延長。

     

以上經驗分享，結合到具體工做，可能有場景須要考慮： 

  
• 近幾年很多研發團隊逐步往快速迭代方向轉移，其中應當更多地關注目前代碼的內部質量，是否有足夠的單元測試保證代碼的穩定性，是否不斷地在進行重構保證代碼的簡潔。在快速應對變化的同時，代碼不能絲毫打折扣。咱們要常常反思，咱們估計的時間，是否已經考慮給開發團隊預留了足夠的重構時間？產品經理是否足夠的瞭解代碼目前的質量狀態？咱們是否在欠債？ 

  
• 對於維護現有代碼，咱們常常是直接野蠻的在原有代碼中繼續累加邏輯，不多考慮重構，致使原有邏輯愈來愈複雜，難以理解。這一點應當受到更多關注。 

 

最後引用一句話，與你們共勉： 

 

  
知識不在於記住多少，而是在於它出發了你多少的思考。一旦咱們開始反思咱們的代碼，代碼將再也不同樣。