經(jīng)歷了幾個從商業(yè)角度來看或成功或失敗的項目，都會發(fā)現(xiàn)代碼、設(shè)計都會慢慢地、在不經(jīng)意間腐化。而且有一個項目開始的時候，架構(gòu)是經(jīng)過精心設(shè)計的，也有較為嚴(yán)格的代碼規(guī)范，并且通過靜態(tài)代碼檢查來盡量保證代碼的質(zhì)量，連code review都有一個可供參考的checklist。但半年一年之后，還是會發(fā)現(xiàn)，很多代碼都已經(jīng)臃腫走樣，到處都是復(fù)制粘貼，動輒好幾千行代碼的模塊，能 work、但不 right的代碼。

getting it work is easy
getting it right is hard

不禁想問問代碼和設(shè)計是如何一步步腐化的？

本文地址：http://www.rzrgm.cn/xybaby/p/13173047.html

代碼如何開始腐爛

其實大家都聽說過 clean code，但不一定真正意識到其重要性，且知道并不等同于做到，而時間更是一把殺豬刀，讓程序員禿了，讓代碼爛了。

一個新項目開始的時候，大家都是滿懷壯志，期待靈活可復(fù)用的架構(gòu)，期待成功的產(chǎn)品。與此同時，敏捷開發(fā)告訴我們不要過度設(shè)計，當(dāng)然，本身也是很難預(yù)料到以后需求變化的方向，于是應(yīng)該等到第一次變化的時候才去考慮如何重構(gòu)以應(yīng)對這一類型的變化。但問題很可能就會出現(xiàn)在這里。

也就是說，也許哪一天，當(dāng)我們需要加一個新功能的時候，會發(fā)現(xiàn)原來的設(shè)計和代碼不是很方便增加這個新功能。當(dāng)然，我們不應(yīng)該過多苛責(zé)之前的設(shè)計，因為以前沒有預(yù)料到這個新功能，也就沒有在這個地方引入抽象。這個時候有兩種解決辦法：第一種是重構(gòu)術(shù)，就是加功能之前先了解、重構(gòu)已有的代碼，比如調(diào)整一下類的基礎(chǔ)體系、抽象出基類、或者引入一個間接層以隔離變化。另一種則是修補術(shù)，在現(xiàn)有的函數(shù)中加一個 if-else（或者 switch case）、在現(xiàn)有的類中加幾個特殊字段。這兩種方法都能解決問題，修補術(shù)治標(biāo)，重構(gòu)術(shù)治本，但顯然，治標(biāo)來得更快，治本對程序員的要求更高。

什么時候程序員會選擇修補術(shù)而不是重構(gòu)術(shù)呢？

也許這個程序員看過 clean code、refactor，精通設(shè)計模式和面向?qū)ο螅卜浅ＯＭS護(hù)一份漂亮的代碼。但我們知道，重構(gòu)是需要時間的，而且還可能引入bug。也許重構(gòu)耗費的時間就超過了用修補術(shù) workaround 的時間，就短期來說，修補術(shù)的性價比是更高的。那么長遠(yuǎn)來說呢，也許重構(gòu)術(shù)的性價比更高？可是只顧眼前、及時行樂是人的本能，走捷徑、偷懶是無時不存在的誘惑。當(dāng)然，也許有追求的程序員會抵制這種誘惑，但是社會心理學(xué)告訴我們，在壓力、干擾面前我們很難理智思考，自控力也會失效。時間、進(jìn)度壓力就是垂懸在程序員頭上的達(dá)摩克利斯之劍，這壓力可能讓人失眠、讓人頭禿，寫點垃圾代碼似乎也無可厚非。

況且，重構(gòu)還可能引入bug，重構(gòu)的前提是要有完備的測試機制，單元測試、功能測試、集成測試一個都不能少?？墒?，理想很豐滿，現(xiàn)實很骨感，單元測試覆蓋率往往不足，而且還可能依靠手動回歸測試。把代碼重構(gòu)好了可能壓根沒人知道，沒人來感謝你、給你點個贊，但萬一重構(gòu)出了bug呢，大家都會收到事故報告，說不定還會影響KPI？不求有功但求無過，Leader、經(jīng)理是否認(rèn)可重構(gòu)的價值，也很大程度影響組員對于重構(gòu)的積極性。

當(dāng)然，增加新功能的也許是一個新手，新手加入團(tuán)隊后，一般就是從維護(hù)某個模塊，實現(xiàn)一些小需求入手。新手有可能水平本身就不行，而且業(yè)務(wù)邏輯和代碼都是陌生的，如果缺乏完善的文檔以及足夠的掌握，新手是萬萬不敢重構(gòu)的，修補術(shù)是最自然的選擇，復(fù)制、粘貼、稍微修改一下、build、run，成功啦！又實現(xiàn)了一個需求！你知道，新人是急于證明自己的，快速的實現(xiàn)一個又一個需求是證明自己的最佳辦法。

你有可能說，新人不是應(yīng)該有個導(dǎo)師嗎，導(dǎo)師得review新人的代碼啊。首先，導(dǎo)師得懂這一塊業(yè)務(wù)；其次，導(dǎo)師得愿意花時間指導(dǎo)新人。指導(dǎo)新人是否影響導(dǎo)師的KPI呢？帶好了是否有獎，出問題了是否有懲？如果全憑導(dǎo)師自律，這個不確定性就太大了。

上面提到的是新人，其實老手也可能寫出“德不配位”的代碼，比如一個需求，可能涉及到多個模塊，有的模塊是這個老手負(fù)責(zé)的，有的則不是。理想的情況下，各個模塊提供好接口供老手調(diào)用即可，但某個模塊的負(fù)責(zé)人很忙，沒有時間，這個時候老手就會直接去修改相應(yīng)模塊。可是，可能由于老手特有的自尊、或者面子，老手往往不愿意去請教對應(yīng)模塊的負(fù)責(zé)人，而是按照自己的經(jīng)驗?zāi)Ц某鲆欢慰梢怨ぷ?，但既不?yōu)雅、也不高效的代碼。

代碼如何加速腐爛

所以說，由于進(jìn)度壓力、經(jīng)驗、態(tài)度等各種各樣的原因，代碼中慢慢就會開始出現(xiàn)腐朽的問題。可怕的是，垃圾的代碼給出了錯誤的示范，這種示范對于新手或者對于這個模塊不熟悉的同事來說都很強烈，也使得垃圾的代碼、倍增的維護(hù)成本、潛在的bug被到處復(fù)制，美其名曰“借鑒”。破窗效應(yīng)，讓后來人寫出垃圾代碼的時候毫無心理負(fù)擔(dān)，“以前就是這個樣子的”，以前這里有個變量叫temp，我只是加了個變量叫temp1；以前這里就有switch case，我只不過加了一個case；以前的代碼就很難讀懂了，于是我copy的一份實現(xiàn)自己的邏輯。

況且，到項目后期，可能不再那么掙錢了，可能最初寫代碼、制定規(guī)范的人已經(jīng)不再了，誰還會來關(guān)心這代碼質(zhì)量呢？

悲觀的認(rèn)為，代碼的腐化是必要，只是時間快慢問題。