整潔又好看的代碼是什么？我們又該如何實現？

 最近，我們公司內部一直在討論如何寫出整潔的代碼的相關研討會，他們認為一份整潔的代碼能為團隊開發，后期維護，重構奠定了良好的基礎，其質量也是可靠的。因此各小組以如何建立并監督編碼標準展開了大量的討論。雖然我同意這類作法確實有一定的作用，但我認為整潔代碼最核心的關鍵并不是這個。因此，以下內容是我個人對整潔代碼的理解與看法。

首先，我個人認為整潔代碼這一說法并不準確。這一術語很容易誤導大家以為僅僅是讓代碼看起來更加整潔就可以了，而這顯然是很膚淺的表面現象。相反，我認為將它稱為“宜居型代碼”更為合適，正如Richard Gabriel所說：

宜居型代碼是源代碼的一種特性，即允許程序員、編碼者、bug修復者以及其他人在首次閱讀代碼的人能很清晰的明白這里在干什么，而不是隱澀難懂，并能很快的加以調整。

宜居型代碼會讓人有種賓至如歸的體驗，只有這樣，開發者才能在無需深入考量的前提下快速著手工作。

雖然良好的代碼格式，會使得我們閱讀更容易且查找更快速，但其本質的宜居型是關鍵。在我看來，宜居型代碼是指代碼能隨著業務的需求任意改變的。因此，在小規模業務要求調整代碼時只需要投入低成本的代價就可實現，而當大規模業務要求調整代碼時只需要再投入較多的開發成本即可實現——因為新需求與現有代碼庫不相契合，所以無法共享原有的代碼。

考慮到這一定義，我認為宜居型代碼的關鍵在于整體結構。而只有頂層設計（架構）能夠將宜居型的特性變為現實。而最佳實現途徑包括以下幾項：

• 應用程序要被劃分為多個（不應過多）模塊。
• 每個模塊代表著其領域里的一個特定意義， 其命名要一目了然，且不存在歧義，并要確保首次閱讀代碼的人能快速了解其作用。
• 各模塊要擁有一個經過良好定義的接口，同樣要有一個特定且唯一的名字來命名。
• 每個模塊的生命周期和各個模塊之間的關系是以聲明方式在應用程序的入口點中表示。具體來講，應用入口點必須明確聲明這些模塊是以何種方式來對接的，并要提供必要的業務價值。
• 各模塊間的共生性要在各層級代碼得到明確表達。

（這部分內容其實就是對結構化程序設計方法的再次重申。正如之前提到，我并沒有創造任何新鮮概念。）

在我看來，這些模塊屬于形式與功能的組合——命名是區分應用區，而行為是描述業務。不同模塊間的關系應當得到聲明，且不存在任何隱藏或任何歧義，直接了當表明關系。

我還認為，這一定義同樣適用于遞歸。著眼于任何頂級模塊，其中每個模塊都應與整體應用顯示出同樣的特性：

• 拆分為多個（不能太多）子模塊。
• 每個子模塊要擁有一個經過良好定義的接口。
• 各子模塊的關系與生命周期應在該模塊的入口點中聲明。
• 各子模塊間的共生性應在代碼中得到明確表達。

這些嵌套模塊可以作為應用、微服務、軟件包、命名空間、綁定上下文、聚合、模塊、對象乃至功能形式存在——這一切皆可被視為“封裝單元”或者“對象”。

• 這一原則與Page-Jones重構算法能夠相互印證：

• 將應用劃分為多個（不能太多）模塊。

• 移除各模塊間的全部高階共生性。

• 遞歸直至無意義。

任何模塊的拆分其子模塊都能代表著另一組實現。并且我希望能夠將各個模塊作為一個黑匣子看待，且能在無沖突前提下對黑匣子邊界進行重構。這需要該模塊的接口有個一良好定義（例如通過自動化測試實現），且各模塊間及子模塊間的共生性明確且可理解。

在我看來，隨著層級降低，利用這一算法的價值也將隨之降低。換言之，明確頂層模塊的關系，其價值要高于明確底層子模塊間的關系。這樣的應用更易于變更，特別是考慮到頂層代碼要采取簡單的表達方式。雖然整潔的低級別模塊同樣能帶來好處，但實現應用宜居型的整體收益相對較低。

作為實現手段之一，我認為面向消息型編程能夠在各類規模下能達到良好的收效。我之所以將應用劃分成多個模塊，單純是為了讓各模塊間的通信變得簡單且意義明確。模塊的存在只是為了隱藏消息以及層的變更是如何實際“生效”的。Michael Feathers提出的Naked CRC技術同樣能夠很好地實現宜局型模塊的通信。

遺憾的是，我所見過的大部分代碼庫都粗暴地違反了以上各種實現模式。其通常包含著數百個毫無結構性可言的類，這些類全部存在于同一抽象及可訪問層內。這樣的代碼庫絕無宜人性可言，且很難向其中添加新的類或者概括其中現有類的作用。這類應用同樣難于重構，因為大多數“單元測試”機制著眼于實現選擇的而非業務要求。而且由于不具備頂層封裝的單元，因此我們很難理解其整體設計思路。

來自：http://developer.51cto.com/art/201612/525096.htm