來源： Stack Huang
很多團隊都有這個問題，一個專案的程式碼本來開始設計得好好的，一段時間以後，程式碼就會變得難以理解，難以維護，難以修改。為什麼？我一直在思考這個問題。
讓我們先看一個人的情況。
1.程式設計師的成長
新手的程式碼
新手的程式碼沒有經驗，基本不考慮程式碼設計，程式碼規模稍稍大一點則自己就亂了。
進階者的程式碼
小規模的時候
大規模的時候
進階者已經知道如何設計程式碼，懂得程式碼規則，但一般侷限於一個模組。規模一大，模組間的呼叫就會比較混亂，難以維護。
有經驗者的程式碼
有經驗者的程式碼，模組內部程式碼整潔，模組之間層次清晰，有設計模式，有成熟的體系。可以保持長期的程式碼整潔。
那麼一個團隊裡面會出現什麼情況呢？似乎，我們只要讓一堆有經驗的人來開發，那麼程式碼必然不會出什麼問題。可惜，事實不是這樣。
2.背景
程式碼風格的多樣性
有這樣的。
也有這樣的
放眼一看，會發現不同的程式碼風格，不同的設計思想，不同的設計理念。每個程式設計師都有自己的程式碼個性。
團隊層次的差異
一個團隊內部有新人，有熟手，有牛人。一個設計好的架構可能會變壞。
3.原因
風格的融合
當程式設計師A和程式設計師B在一起的時候，會有如下變化
原本整潔的程式碼變得不整潔了。
進度的壓力
進度導致了“飛線”的產生，未經設計的程式碼在時間的藉口下產生了。
多個人修改一個模組
4.本質
所有程式碼腐爛問題的本質是溝通問題。其表現又都可以統一為修改別人的程式碼。
當一個程式設計師在沒有溝通的情況下，修改另一個程式設計師的模組的程式碼的時候，他可能不理解此模組的設計思路，程式碼結構，邏輯結構，於是按自己的想法去修改，雖然看起來解決了眼前的問題。但是留下了一個不穩定因素。此因素可以通過重構來解決。但是，大家都非常的“忙”，誰也沒有空時間去Review程式碼，去溝通我改了你的哪裡的程式碼。所以不穩定的因素越來越多，導致了程式碼的腐爛。
最快腐爛的程式碼，一定是很多人在修改的程式碼，相反，長期由一個人來維護的程式碼，就不會那麼容易腐爛。因為一個人不存在溝通的問題，他修改程式碼的時候，明確的知道自己應該怎樣去修改，怎樣讓程式碼更整潔。
5.解決
就一個辦法，多溝通。
當你工作的時候需要修改別人的程式碼的時候，應該先找這個人溝通。說清楚需要改動的邏輯，然後儘量讓他來修改。這樣可以保證一塊程式碼是由一個人維護，這樣成本最少。
如果此人真的太忙，沒有時間，那麼你必須說明你的計劃，讓他做一個建議，最好能讓他給你講講此模組的設計思路，程式碼設計，邏輯設計，現在的問題，以後的計劃。保證你修改的程式碼都是合理的。
最理想的狀態就是整個團隊的思想是高度統一的，N個人可以像一個人那樣去工作。這個需要團隊長期的磨合。
你可以會想到，我們制定一個規範不就可以了麼？紙面上的規範通常是不起作用的，成功團隊的規範是在整個團隊達到一個很高的水平以後總結的經驗。與其說執行規範，不如說是學習經驗。MFC的程式碼像是由一個人寫出來的，Office所有產品都像是一個人做出來的。這就是高度的統一。我們把微軟的規範搬過來，不一定就有效果。
程式碼的腐爛都是由於沒有深入理解的情況下修改別人的程式碼導致的。
總結一下：
- 解決的方法就是任何修改之前確保經過深入的溝通。
- 簡單的規則是一個模組僅允許一個人維護。
- 理想的狀態是整個團隊思想高度統一。
_