寫代碼如同打掃屋子，有句話叫一屋不掃何以掃天下。如果單個的一個模塊代碼都不能管好，如何成就一個完善的軟件系統？今天我們來說說，一個代碼模塊的代碼是如何一步步腐化變質，到最后程序員都不愿意去維護它，然后要么重構，要么廢棄換新模塊的？
代碼是有一定的周期的，這個沒有錯。為什么有的代碼跑上幾十年任然好用，而現在互聯網公司的很多代碼，每年都要做好幾次重構？一個成立2年的互聯網公司，做一個支付系統，可以做了4-5代，每次重構，這樣的代價有多大？如何才能讓原有的代碼生命周期更加長，而不增加很多的學習維護成本，開發(fā)一次使用更久呢？
大部分程序員是沒有很多機會從0開始搭建一個新程序的，更多的時候是接手別人寫的代碼。有代碼移交還好一點，往往因為各種因素，這些因素你懂的，沒有產品文檔，沒有設計文檔，沒有程序說明，程序里可能連注釋都沒有。然后，程序員更新換代又極其的快，互聯網時代，程序員在一個公司的平均年資也就1年多，程序就又被傳給下一任維護者。很大可能的情況是，最終到你手里的程序各種問題，卻能實現基本的功能需求，但代碼內部各種問題讓程序員總有一個沖動，重構它。
今天不想說重構的問題，而是從根源角度分析，程序為什么會變成這個樣子？
什么是程序的腐化？
什么是一個軟件的質量？一個分類標準是軟件外部質量與軟件內部質量的統一，外部質量是對外表現是否正常，內部質量是對后續(xù)開發(fā)有沒有坑，就是我在這里說的軟件有沒有腐化。內部質量標準有：可維護性，靈活性，可移植性，可重用性，可測試性，可理解性（摘錄自代碼大全）。不符合以上標準都可以稱之為代碼腐化，形象的理解就是一個蘋果，從內部開始爛了，爛到原本應該負責內部代碼的程序員拒絕去維護了。
實際的代碼腐化的例子：
代碼混亂，沒有代碼規(guī)范
不該連數據庫的模塊連了數據庫
模塊間的調用混亂：
模塊內部的調用混亂，例如C#代碼已經使用了EntityFramework，代碼中跳過EntityFramework，直接用數據庫連接修改數據。
框架與其他不一致，不統一：有的包管理使用gradle管理，有的使用maven。有的后臺用.Net，有的用Node，有的用Java。用了HttpClient，又使用Feign去連接其他應用模塊
有一些設計前后不一致：有的代碼使用了統一的錯誤定義CommonException，有的用原生的Exception。微服務模塊，有resource層接口，定義訪問的路徑，resource的Impl，service的接口提供具體的數據接口，serviceImpl提供具體數據獲取的實現。而在具體編碼時，將大量的業(yè)務邏輯寫入了resource的實現中。
太復雜的抽象不能做方便的變更：一開始設計的Job系統，上面是2-3張圖片，下面是動態(tài)生成的問題。代碼層面對于此設計做了很細致的抽象。突然產品提出了某一個Job的圖片有特別，要求顯示10張圖片，就對抽象的圖片部分做了if-else的處理……
無用代碼，廢棄的接口沒有標明
代碼腐化的原因
沒有代碼會是init commit的時候就開始腐化的，腐化都是循序漸進的，要一個過程。我總結了一些代碼腐化的原因：
