代碼和設計是如何一步步腐化的

經曆了幾個從商業角度來看或成功或失敗的項目，都會發現代碼、設計都會慢慢地、在不經意間腐化。而且有一個項目開始的時候，架構是經過精心設計的，也有較為嚴格的代碼規範，并且通過靜态代碼檢查來盡量保證代碼的品質，連code review都有一個可供參考的checklist。但半年一年之後，還是會發現，很多代碼都已經臃腫走樣，到處都是複制粘貼，動辄好幾千行代碼的子產品，能 work、但不 right的代碼。

getting it work is easy

getting it right is hard

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

本文位址：https://www.cnblogs.com/xybaby/p/13173047.html

代碼如何開始腐爛

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

一個新項目開始的時候，大家都是滿懷壯志，期待靈活可複用的架構，期待成功的産品。與此同時，靈活開發告訴我們不要過度設計，當然，本身也是很難預料到以後需求變化的方向，于是應該等到第一次變化的時候才去考慮如何重構以應對這一類型的變化。但問題很可能就會出現在這裡。

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

什麼時候程式員會選擇修補術而不是重構術呢？

也許這個程式員看過 clean code、refactor，精通設計模式和面向對象，也非常希望維護一份漂亮的代碼。但我們知道，重構是需要時間的，而且還可能引入bug。也許重構耗費的時間就超過了用修補術 workaround 的時間，就短期來說，修補術的成本效益是更高的。那麼長遠來說呢，也許重構術的成本效益更高？可是隻顧眼前、及時行樂是人的本能，走捷徑、偷懶是無時不存在的誘惑。當然，也許有追求的程式員會抵制這種誘惑，但是社會心理學告訴我們，在壓力、幹擾面前我們很難理智思考，自控力也會失效。時間、進度壓力就是垂懸在程式員頭上的達摩克利斯之劍，這壓力可能讓人失眠、讓人頭秃，寫點垃圾代碼似乎也無可厚非。

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

當然，增加新功能的也許是一個新手，新手加入團隊後，一般就是從維護某個子產品，實作一些小需求入手。新手有可能水準本身就不行，而且業務邏輯和代碼都是陌生的，如果缺乏完善的文檔以及足夠的掌握，新手是萬萬不敢重構的，修補術是最自然的選擇，複制、粘貼、稍微修改一下、build、run，成功啦！又實作了一個需求！你知道，新人是急于證明自己的，快速的實作一個又一個需求是證明自己的最佳辦法。

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

上面提到的是新人，其實老手也可能寫出“德不配位”的代碼，比如一個需求，可能涉及到多個子產品，有的子產品是這個老手負責的，有的則不是。理想的情況下，各個子產品提供好接口供老手調用即可，但某個子產品的負責人很忙，沒有時間，這個時候老手就會直接去修改相應子產品。可是，可能由于老手特有的自尊、或者面子，老手往往不願意去請教對應子產品的負責人，而是按照自己的經驗魔改出一段可以工作，但既不優雅、也不高效的代碼。

代碼如何加速腐爛

是以說，由于進度壓力、經驗、态度等各種各樣的原因，代碼中慢慢就會開始出現腐朽的問題。可怕的是，垃圾的代碼給出了錯誤的示範，這種示範對于新手或者對于這個子產品不熟悉的同僚來說都很強烈，也使得垃圾的代碼、倍增的維護成本、潛在的bug被到處複制，美其名曰“借鑒”。破窗效應，讓後來人寫出垃圾代碼的時候毫無心理負擔，“以前就是這個樣子的”，以前這裡有個變量叫temp，我隻是加了個變量叫temp1；以前這裡就有switch case，我隻不過加了一個case；以前的代碼就很難讀懂了，于是我copy的一份實作自己的邏輯。

況且，到項目後期，可能不再那麼掙錢了，可能最初寫代碼、制定規範的人已經不再了，誰還會來關心這代碼品質呢？

悲觀的認為，代碼的腐化是必要，隻是時間快慢問題。

本文版權歸作者xybaby（博文位址：http://www.cnblogs.com/xybaby/）所有，歡迎轉載和商用，請在文章頁面明顯位置給出原文連結并保留此段聲明，否則保留追究法律責任的權利，其他事項，可留言咨詢。