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

原創做品，容許轉載，轉載時請務必以超連接形式標明文章 原始出處 、做者信息和本聲明。不然將追究法律責任。 http://powertoolsteam.blog.51cto.com/2369428/1298688

本文主要關注代碼的內部和外部質量，編程的價值觀，代碼質量的評估標準，整潔代碼的匠藝以及如何維護已有的代碼。

外部質量：用戶所能感覺到的部分，正確性，易用性，效率，可靠性。

內部質量（代碼質量）：可維護性，靈活性，可移植性，重用，可讀性，可測試性，可理解性。

總結的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% 的時間用做保持對原有系統的重構。剩餘的時間用做開發新功能。

    • 只要有可能，對所要重構的部分進行遞增修改，讓用戶切身感覺到產品的改進，哪怕將工做時間延長。

    
    

    
    

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

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

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

最後引用一句話，與你們共勉：
知識不在於記住多少，而是在於它出發了你多少的思考。一旦咱們開始反思咱們的代碼，代碼將再也不同樣。

本文出自 「葡萄城控件博客」 博客，請務必保留此出處http://powertoolsteam.blog.51cto.com/2369428/1298688