很多團隊都有這個問題，一個項目的代碼本來開始設計得好好的，一段時間以后，代碼就會變得難以理解，難以維護，難以修改。為什么？我一直在思考這個問題。

　　讓我們先看一個人的情況。

　　1.?程序員的成長

　　新手的代碼

　　新手的代碼沒有經驗，基本不考慮代碼設計，代碼規模稍稍大一點則自己就亂了。

　　進階者的代碼

　　小規模的時候

　　大規模的時候

　　進階者已經知道如何設計代碼，懂得代碼規則，但一般局限于一個模塊。規模一大，模塊間的調用就會比較混亂，難以維護。

　　有經驗者的代碼

　　有經驗者的代碼，模塊內部代碼整潔，模塊之間層次清晰，有設計模式，有成熟的體系。可以保持長期的代碼整潔。

　　那么一個團隊里面會出現什么情況呢？似乎，我們只要讓一堆有經驗的人來開發，那么代碼必然不會出什么問題。可惜，事實不是這樣。

　　2.?背景

　　代碼風格的多樣性

　　有這樣的。

　　也有這樣的

　　放眼一看，會發現不同的代碼風格，不同的設計思想，不同的設計理念。每個程序員都有自己的代碼個性。

　　團隊層次的差異

　　一個團隊內部有新人，有熟手，有牛人。一個設計好的架構可能會變壞。

　　3.?原因

　　風格的融合

　　當程序員A和程序員B在一起的時候，會有如下變化

　　原本整潔的代碼變得不整潔了。

　　進度的壓力

　　進度導致了“飛線”的產生，未經設計的代碼在時間的借口下產生了。

　　多個人修改一個模塊

　　4.?本質

　　所有代碼腐爛問題的本質是溝通問題。其表現又都可以統一為修改別人的代碼。

　　當一個程序員在沒有溝通的情況下，修改另一個程序員的模塊的代碼的時候，他可能不理解此模塊的設計思路，代碼結構，邏輯結構，于是按自己的想法去修改，雖然看起來解決了眼前的問題。但是留下了一個不穩定因素。此因素可以通過重構來解決。但是，大家都非常的“忙”，誰也沒有空時間去 Review 代碼，去溝通我改了你的哪里的代碼。所以不穩定的因素越來越多，導致了代碼的腐爛。

　　最快腐爛的代碼，一定是很多人在修改的代碼，相反，長期由一個人來維護的代碼，就不會那么容易腐爛。因為一個人不存在溝通的問題，他修改代碼的時候，明確的知道自己應該怎樣去修改，怎樣讓代碼更整潔。

　　5. 解決

　　就一個辦法，多溝通。

　　當你工作的時候需要修改別人的代碼的時候，應該先找這個人溝通。說清楚需要改動的邏輯，然后盡量讓他來修改。這樣可以保證一塊代碼是由一個人維護，這樣成本最少。

　　如果此人真的太忙，沒有時間，那么你必須說明你的計劃，讓他做一個建議，最好能讓他給你講講此模塊的設計思路，代碼設計，邏輯設計，現在的問題，以后的計劃。保證你修改的代碼都是合理的。

　　最理想的狀態就是整個團隊的思想是高度統一的，N個人可以像一個人那樣去工作。這個需要團隊長期的磨合。

　　你可以會想到，我們制定一個規范不就可以了么？紙面上的規范通常是不起作用的，成功團隊的規范是在整個團隊達到一個很高的水平以后總結的經驗。與其說執行規范，不如說是學習經驗。MFC 的代碼像是由一個人寫出來的，Office 所有產品都像是一個人做出來的。這就是高度的統一。我們把微軟的規范搬過來，不一定就有效果。

　　代碼的腐爛都是由于沒有深入理解的情況下修改別人的代碼導致的。

　　總結一下：

• 解決的方法就是任何修改之前確保經過深入的溝通。
• 簡單的規則是一個模塊僅允許一個人維護。
• 理想的狀態是整個團隊思想高度統一。