經歷了幾個從商業角度來看或成功或失敗的專案，都會發現程式碼、設計都會慢慢地、在不經意間腐化。而且有一個專案開始的時候，架構是經過精心設計的，也有較為嚴格的程式碼規範，並且通過靜態程式碼檢查來儘量保證程式碼的質量，連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的一份實現自己的邏輯。
況且，到專案後期，可能不再那麼掙錢了，可能最初寫程式碼、制定規範的人已經不再了，誰還會來關心這程式碼質量呢？
悲觀的認為，程式碼的腐化是必要，只是時間快慢問題。