|
|
很多團(tuán)隊都有這個問題，一個項目的代碼本來開始設(shè)計得好好的，一段時間以后，代碼就會變得難以理解，難以維護(hù)，難以修改。為什么？我一直在思考這個問題。
讓我們先看一個人的情況。
1. 程序員的成長
新手的代碼
新手的代碼沒有經(jīng)驗，基本不考慮代碼設(shè)計，代碼規(guī)模稍稍大一點則自己就亂了。
進(jìn)階者的代碼
小規(guī)模的時候
大規(guī)模的時候
進(jìn)階者已經(jīng)知道如何設(shè)計代碼，懂得代碼規(guī)則，但一般局限于一個模塊。規(guī)模一大，模塊間的調(diào)用就會比較混亂，難以維護(hù)。
有經(jīng)驗者的代碼
有經(jīng)驗者的代碼，模塊內(nèi)部代碼整潔，模塊之間層次清晰，有設(shè)計模式，有成熟的體系。可以保持長期的代碼整潔。
那么一個團(tuán)隊里面會出現(xiàn)什么情況呢？似乎，我們只要讓一堆有經(jīng)驗的人來開發(fā)，那么代碼必然不會出什么問題。可惜，事實不是這樣。
2. 背景
代碼風(fēng)格的多樣性
有這樣的。
也有這樣的
放眼一看，會發(fā)現(xiàn)不同的代碼風(fēng)格，不同的設(shè)計思想，不同的設(shè)計理念。每個程序員都有自己的代碼個性。
團(tuán)隊層次的差異
一個團(tuán)隊內(nèi)部有新人，有熟手，有牛人。一個設(shè)計好的架構(gòu)可能會變壞。
3. 原因
風(fēng)格的融合
當(dāng)程序員A和程序員B在一起的時候，會有如下變化
原本整潔的代碼變得不整潔了。
進(jìn)度的壓力
進(jìn)度導(dǎo)致了“飛線”的產(chǎn)生，未經(jīng)設(shè)計的代碼在時間的借口下產(chǎn)生了。
多個人修改一個模塊
4. 本質(zhì)
所有代碼腐爛問題的本質(zhì)是溝通問題。其表現(xiàn)又都可以統(tǒng)一為修改別人的代碼。
當(dāng)一個程序員在沒有溝通的情況下，修改另一個程序員的模塊的代碼的時候，他可能不理解此模塊的設(shè)計思路，代碼結(jié)構(gòu)，邏輯結(jié)構(gòu)，于是按自己的想法去修改，雖然看起來解決了眼前的問題。但是留下了一個不穩(wěn)定因素。此因素可以通過重構(gòu)來解決。但是，大家都非常的“忙”，誰也沒有空時間去 Review 代碼，去溝通我改了你的哪里的代碼。所以不穩(wěn)定的因素越來越多，導(dǎo)致了代碼的腐爛。
最快腐爛的代碼，一定是很多人在修改的代碼，相反，長期由一個人來維護(hù)的代碼，就不會那么容易腐爛。因為一個人不存在溝通的問題，他修改代碼的時候，明確的知道自己應(yīng)該怎樣去修改，怎樣讓代碼更整潔。
5. 解決
就一個辦法，多溝通。
當(dāng)你工作的時候需要修改別人的代碼的時候，應(yīng)該先找這個人溝通。說清楚需要改動的邏輯，然后盡量讓他來修改。這樣可以保證一塊代碼是由一個人維護(hù)，這樣成本最少。
如果此人真的太忙，沒有時間，那么你必須說明你的計劃，讓他做一個建議，最好能讓他給你講講此模塊的設(shè)計思路，代碼設(shè)計，邏輯設(shè)計，現(xiàn)在的問題，以后的計劃。保證你修改的代碼都是合理的。
最理想的狀態(tài)就是整個團(tuán)隊的思想是高度統(tǒng)一的，N個人可以像一個人那樣去工作。這個需要團(tuán)隊長期的磨合。
你可以會想到，我們制定一個規(guī)范不就可以了么？紙面上的規(guī)范通常是不起作用的，成功團(tuán)隊的規(guī)范是在整個團(tuán)隊達(dá)到一個很高的水平以后總結(jié)的經(jīng)驗。與其說執(zhí)行規(guī)范，不如說是學(xué)習(xí)經(jīng)驗。MFC 的代碼像是由一個人寫出來的，Office 所有產(chǎn)品都像是一個人做出來的。這就是高度的統(tǒng)一。我們把微軟的規(guī)范搬過來，不一定就有效果。
代碼的腐爛都是由于沒有深入理解的情況下修改別人的代碼導(dǎo)致的。
總結(jié)一下：
- 解決的方法就是任何修改之前確保經(jīng)過深入的溝通。
- 簡單的規(guī)則是一個模塊僅允許一個人維護(hù)。
- 理想的狀態(tài)是整個團(tuán)隊思想高度統(tǒng)一。
it知識庫：如何防止代碼腐爛，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
