什麼樣的程式碼才是好程式碼？衡量程式碼的好壞的指標或者維度有很多，比如效能好、架構好、高內聚等，這些指標的側重點各不相同，不同的開發人員的關注的重點也各不相同。我個人更喜歡簡單的可讀性高的程式碼，我主要從以下幾個維度衡量程式碼是否良好：

程式碼是可工作的

寫程式碼的目的是要為了解決特定問題的，因此無論如何，程式碼首先是可工作的，能解決特定的問題。可工作的包含有兩層含義：一是從功能角度來說能滿足使用者的需求，二是從效能角度來說要滿足當前基本的效能需求。所以可工作是衡量程式碼好壞的前置條件，只考慮程式碼本身不考慮可工作性是捨本取末。

程式碼是可讀性高的

程式碼是開發人員來開發和維護的，而且在軟體漫長的生命週期中，通常會由不同的開發人員來維護的，如果程式碼的可讀性很差，那將來的維護就將是一個噩夢。我們寫的程式碼是給開發人員看的，絕對不是給機器看的(編譯後的程式碼是給機器看的，編譯器會幫我們去掉無意義的空行等)，因此程式碼必須首先是可讀性高的。

那什麼是可讀性高的程式碼呢?從 coding style 角度來說，有意義的命名、新增必要的文件和註釋、類和方法不要太長、每一行也不要太長、新增必要的空行以及必要的縮排等，具體可以參考《C++程式設計規範》和《重構改善既有程式碼的設計》。另外一方面就是從程式碼的結構來定義，例如程式碼是高內聚、低耦合的，程式碼是簡單的，這三個方面下面會有詳細描述。

程式碼是簡單的

我們先來看一下什麼是複雜的程式碼，比如說美其名曰為了程式碼的擴充套件性，使用了好多設計模式和軟體開發原則，結果就是明明可以用很簡單幾行程式碼搞定的事情，結果用了幾十行程式碼甚至更多，而且程式碼用了各種酷炫的技術，但是事實上大部分的擴充套件性可能一輩子也沒有發生過，從敏捷開發角度來說，這是非常典型的過度設計。敏捷開發不是不考慮設計，只是不推崇過度設計，比如考慮 10 年後

所以在適度考慮程式碼的可擴充套件性的基礎上，能不用設計模式就不要用設計模式，能不用新的、複雜的技術就不用新的、複雜的技術，技術夠用就好，程式碼越簡單越好，有人說程式碼太簡單是不是有點 low，其實寫出高質量的簡單程式碼遠比寫出複雜的程式碼難度高，尤其是系統比較複雜時，保持程式碼的簡單性難度是非常大的。

所以說簡單的程式碼就是：程式碼所有人都看得懂，尤其是新人，但是又具備一定的擴充套件性和維護性，簡單的講就是簡約而不簡單。複雜的程式碼首先對讀程式碼的人要求就很高，最終導致程式碼很難維護。程式碼是簡單的是程式碼可讀性高的一個方面。

程式碼是高內聚的

內聚是從功能角度來度量模組內的聯絡，程式碼關聯性比較強的程式碼應該放在內聚在一起，形成一個獨立的功能模組，可以是一個獨立的類，也可以是一個微服務。其實判斷程式碼是否內聚一個比較簡單的方法就是看你能否給程式碼或者服務給一個貼切的名字，如果程式碼功能不內聚，我們是很難用一個簡短的名字來表示它的含義的。

程式碼是低耦合的

耦合性(Coupling)，也叫耦合度，是對模組間關聯程度的度量。耦合的強弱取決與模組間介面的複雜性、呼叫模組的方式以及通過介面傳送資料的多少。模組間的耦合度是指模組之間的依賴關係，包括控制關係、呼叫關係、資料傳遞關係。模組間聯絡越多，其耦合性越強，同時表明其獨立性越差。

耦合比較高的程式碼危害比較大，最常見的表現就是改一個模組的程式碼會影響許多其它模組，最終必然導致大家不敢修改舊的程式碼，只能不停的新增新的介面，系統的可維護性非常差。