溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文主要關注代碼的內部和外部質量，編程的價值觀，代碼質量的評估標準，整潔代碼的匠藝以及如何維護已有的代碼。
外部質量：用戶所能感受到的部分，正確性，易用性，效率，可靠性。
內部質量（代碼質量）：可維護性，靈活性，可移植性，重用，可讀性，可測試性，可理解性。
總結的22條經驗如下：
代碼分為外部質量和內部質量，好的產品不等于好的代碼（Good Software != Quality Code）。
產品的冰山效應：產品經理以及用戶關注的部分只是冰山露在水面以上的部分，隱藏在下面的是看不見的更加龐大的部分，那就是我們龐大的代碼。
拒絕 PPT 架構師，架構師應當寫代碼，哪怕這些代碼并不 Check-in 到最終的代碼庫中。一個好的設計不是在憑空產生的，而是經過不斷打磨、修改進而獲得的。不存在一次設計，程序猿無腦堆砌代碼能夠完成的好的程序。
編程的價值觀：溝通、簡單、靈活。
代碼最重要的功能是傳遞程序員的設計和思路，其次才是實現的功能。好的程序員應當寫出人類能夠看懂的代碼，而不是機器能理解的代碼。
效率不是犧牲清晰性的理由，不能夠因為人主觀“認為”的一些小伎倆，使用晦澀的代碼，企圖以此提升性能。應當依賴編譯器本身的優化，依賴工具對性能低下的點進行評測，進而進行針對性的優化。
不要試圖死磕代碼加快速度，找個更加有效的算法可能更加有效。
代碼要先做對，在弄快。先使其可靠，再讓其更快。先把代碼弄干凈，再讓它變快。
Good code is not bad code。壞的代碼是可以通過一些指標進行度量的。讓壞代碼的指標可以被機器固化并時時檢查，確保代碼不會變得更糟。
函數本身不是用來復用，這和很多“主流的”觀點不同。函數的存在的主要意義在于：劃分獨立職責，隱藏具體細節操作，使得代碼具有可讀性，應對擴展的變化，方便進行單元測試。順帶的，偶爾可以用作復用。
函數應當遵循：單一抽象層次原則、短小原則和單一職責原則。
當發現一個函數具有以下特征時，需要考慮抽取函數：
過長
嵌套層數過深。
自然分塊，需要使用注釋描述該程序塊
判斷條件過于復雜
函數的某些判斷分支不斷變化
參數過于復雜
邏輯重復
局部變量應當用途單一
新寫代碼邏輯，應當關注用戶場景和類職責劃分，不應當上來就考慮我要使用一個什么模式。這樣勢必會導致過度設計。模式用作應對變化，當后續版本發生變化時，模式用作重構現有代碼。
不斷重構，保持代碼簡潔。
代碼是債務，一個程序員欠下的債務，總是要還的，雖然可能不是由本人還。維護老代碼的程序員又被稱作代碼考古工程師，經常在一大堆糟亂的代碼中挖掘最初的用戶需求，往往這些需求淹沒在無數的變更歷史中。維護老代碼是一個費時費力的過程。需要一些技巧減小修改老代碼的風險。
程序員應當將整潔的代碼風格作為一種習慣，時刻意識到整潔代碼的重要性并不斷地提高重構技巧。
意圖導向編程可以輔助思考，并生成易懂代碼。
設計模式本身是用做應對變化的。如果在開發時就想著“我要用模式”，很可能會導致過度設計。在對代碼進行重構時，才應當考慮使用設計模式解決問題。
函數名稱很重要。
關于注釋：
如果能用短小函數描述，則使用子函數替代注釋本身。
確保注釋和代碼表達的意圖一致，否則就失去了注釋的意義。
在重要的地方寫注釋，不要注釋滿天飛，簡單的重復代碼的功能是毫無意義的。要讓每一處注釋都有價值。不要過分注釋。
關于何時重寫代碼
開發團隊要預留20% 的時間用作保持對原有系統的重構。剩余的時間用作開發新功能。
只要有可能，對所要重構的部分進行遞增修改，讓用戶切身感受到產品的改進，哪怕將工作時間延長。
以上經驗分享，結合到具體工作，可能有場景需要考慮：
近幾年不少研發團隊逐步往快速迭代方向轉移，其中應當更多地關注目前代碼的內部質量，是否有足夠的單元測試保證代碼的穩定性，是否不斷地在進行重構保證代碼的簡潔。在快速應對變化的同時，代碼不能絲毫打折扣。我們要經常反思，我們估計的時間，是否已經考慮給開發團隊預留了足夠的重構時間？產品經理是否足夠的了解代碼目前的質量狀態？我們是否在欠債？
對于維護現有代碼，我們經常是直接野蠻的在原有代碼中繼續累加邏輯，很少考慮重構，導致原有邏輯越來越復雜，難以理解。這一點應當受到更多關注。
最后引用一句話，與大家共勉：
知識不在于記住多少，而是在于它出發了你多少的思考。一旦我們開始反思我們的代碼，代碼將不再一樣。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
