什麼樣的代碼才算是好代碼

小編是一名7年iOS開發人員，在這裡誠摯邀請各位還在堅持iOS的人程式員，不管你是十年大牛還是三年渣碩，肯學肯交流就加入我私人的一個交流群681503716，驗證編碼：大鲨，裡面都有關于iOS的學習資料一起努力進步，我們為iOS付出那麼多，不應該随便放棄吧

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

一、代碼是可工作的

寫代碼的目的是要為了解決特定問題的，是以無論如何，代碼首先是可工作的，能解決特定的問題。可工作的包含有兩層含義：

1、從功能角度來說能滿足使用者的需求

2、從性能角度來說要滿足目前基本的性能需求。

是以可工作是衡量代碼好壞的前置條件，隻考慮代碼本身不考慮可工作性是舍本取末。

二、代碼是可讀性高的

代碼是開發人員來開發和維護的，而且在軟體漫長的生命周期中，通常會由不同的開發人員來維護的，如果代碼的可讀性很差将

來的維護就将是一個噩夢。我們寫的代碼是給開發人員看的，絕對不是給機器看的(編譯後的代碼是給機器看的，編譯器會幫我們去掉無意義的空行等)，是以代碼必須首先是可讀性高的。

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

三、代碼是簡單的

我們先來看一下什麼是複雜的代碼，比如說美其名曰為了代碼的擴充性，使用了好多設計模式和軟體開發原則，結果就是明明可以用很簡單幾行代碼搞定的事情，結果用了幾十行代碼甚至更多，而且代碼用了各種酷炫的技術，但是事實上大部分的擴充性可能一輩子也沒有發生過，從靈活開發角度來說，這是非常典型的過度設計。靈活開發不是不考慮設計，隻是不推崇過度設計，比如考慮 10 年後系統的擴充性是沒有任何意義的，另外一種場景是隻是做一個簡單的背景管理系統，但是卻花大量的精力考慮高并發也是沒有意義的，過度設計的代碼通常是複雜的。

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

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

四、代碼是高内聚的

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

五、代碼是低耦合的

耦合性(Coupling)，也叫耦合度，是對子產品間關聯程度的度量。耦合的強弱取決與子產品間接口的複雜性、調用子產品的方式以及通過界面傳送資料的多少。子產品間的耦合度是指子產品之間的依賴關系，包括控制關系、調用關系、資料傳遞關系。子產品間聯系越多，其耦合性越強，同時表明其獨立性越差。

耦合比較高的代碼危害比較大，最常見的表現就是改一個子產品的代碼會影響許多其它子產品，最終必然導緻大家不敢修改舊的代碼，隻能不停的添加新的接口，系統的可維護性非常差。

本文隻是描述我心中的好代碼，并不打算說明如何編寫好代碼，那需要太多的篇幅和太多的争議。是以，至此為止。