[[230778]]

寫代碼如同打掃屋子，有句話叫一屋不掃何以掃天下。如果單個的一個模塊代碼都不能管好，如何成就一個完善的軟件系統?今天我們來說說，一個代碼模塊的代碼是如何一步步腐化變質，到***程序員都不愿意去維護它，然后要么重構，要么廢棄換新模塊的?

代碼是有一定的周期的，這個沒有錯。為什么有的代碼跑上幾十年任然好用，而現在互聯網公司的很多代碼，每年都要做好幾次重構?一個成立2年的互聯網公司，做一個支付系統，可以做了4-5代，每次重構，這樣的代價有多大?如何才能讓原有的代碼生命周期更加長，而不增加很多的學習維護成本，開發一次使用更久呢?

大部分程序員是沒有很多機會從0開始搭建一個新程序的，更多的時候是接手別人寫的代碼。有代碼移交還好一點，往往因為各種因素，這些因素你懂的，沒有產品文檔，沒有設計文檔，沒有程序說明，程序里可能連注釋都沒有。然后，程序員更新換代又極其的快，互聯網時代，程序員在一個公司的平均年資也就1年多，程序就又被傳給下一任維護者。很大可能的情況是，最終到你手里的程序各種問題，卻能實現基本的功能需求，但代碼內部各種問題讓程序員總有一個沖動，重構它。今天不想說重構的問題，而是從根源角度分析，程序為什么會變成這個樣子?

什么是程序的腐化?

什么是一個軟件的質量?一個分類標準是軟件外部質量與軟件內部質量的統一，外部質量是對外表現是否正常，內部質量是對后續開發有沒有坑，就是我在這里說的軟件有沒有腐化。內部質量標準有：可維護性，靈活性，可移植性，可重用性，可測試性，可理解性(摘錄自代碼大全)。不符合以上標準都可以稱之為代碼腐化，形象的理解就是一個蘋果，從內部開始爛了，爛到原本應該負責內部代碼的程序員拒絕去維護了。

實際的代碼腐化的例子：

代碼混亂，沒有代碼規范不該連數據庫的模塊連了數據庫模塊間的調用混亂：模塊內部的調用混亂，例如C#代碼已經使用了EntityFramework，代碼中跳過EntityFramework，直接用數據庫連接修改數據。框架與其他不一致，不統一：有的包管理使用gradle管理，有的使用maven。有的后臺用.Net，有的用Node，有的用Java。

用了HttpClient，又使用Feign去連接其他應用模塊有一些設計前后不一致：有的代碼使用了統一的錯誤定義CommonException，有的用原生的Exception。微服務模塊，有resource層接口，定義訪問的路徑，resource的Impl，service的接口提供具體的數據接口，serviceImpl提供具體數據獲取的實現。而在具體編碼時，將大量的業務邏輯寫入了resource的實現中。

太復雜的抽象不能做方便的變更：一開始設計的Job系統，上面是2-3張圖片，下面是動態生成的問題。代碼層面對于此設計做了很細致的抽象。突然產品提出了某一個Job的圖片有特別，要求顯示10張圖片，就對抽象的圖片部分做了if-else的處理……無用代碼，廢棄的接口沒有標明

代碼腐化的原因

沒有代碼會是init commit的時候就開始腐化的，腐化都是循序漸進的，要一個過程。我總結了一些代碼腐化的原因：

• 沒有統一標準，或者沒有嚴格執行
• 統一標準之代碼規范

每個程序員都是有自己的審美的，例如即使是縮進長度這種代碼里不影響任何功能的東西，有的喜歡空4格，有的喜歡2格。有的喜歡黑色的編程背景，有的喜歡白色的編程背景。有的喜歡if后直接跟上左括號，有的就喜歡另起一行。代碼規范還是要有的，包含各種格式定義，大小寫規范，命名規范等。前端有各種lint工具(jslint，tslint)可以幫助規范，后臺的ide也有一些方法幫助。像Baidu，Google這樣的公司還有構建時的自開發的檢查工具，所以常常一個資深程序員***次開發的代碼要花上1-2天才能提交通過。代碼規范的混亂，直接導致代碼可讀性的降低。可讀性直接影響后續的生產力。一個程序員天天對著看不順眼的代碼，怎么可能高效?

統一標準之基礎規范

除了代碼規范外，項目命名，通訊方式，基本的程序框架，后端Java的springboot，sprintMVC，前端的angular，vue，react等都需要統一，還有統一的基礎環境(eureka，elk，redis，apigateway等)。不統一的后果是各種部署，管理，編碼的低效。例如搭一個jenkins，然后部署服務A用的Maven，服務B用的gradle，就導致編譯代碼寫2套，如果寫一套基本一樣的，當然會快一些。 我統計的java代碼中可以統一的部分(包含但不限于)Http調用格式，統一用content-type:application/json，response也統一要求這樣。HttpClient的標準化框架,如SpringBoot項目管理工具：Maven，Gradle項目的CI，CD配置管理模式，例如統一成一個配置文件application.properties環境變量配置方式，qa，stag，prod。不要有的人寫stage，staging，也不要寫成production等等細節代碼基礎結構：例如標準的maven目錄的結構

項目命名方式：com.(公司名).(開發組名).(系統名).(模塊名)例如：com.omniprimeinc.cosmetic.application.server;Restful接口設計統一：大小寫，命名方式，Body的***大小例如，Post接口是否可以加PathParameter和QueryParameter。Post接口是否可以不帶Body。其他配套功能的統一性：調用鏈，動態配置管理，緩存，分布式事物數據庫的統一：統一數據庫，數據庫版本，是否可以使用存儲過程等。關于數據庫統一性不在這里展開，這點也非常的重要。

統一規范之公司統一框架

剛才說的統一，很多是從公司層面的統一，如果大家都只用springboot，都沿用統一的后端框架，前端統一用angular。那么這個時候，為了方便統一，就需要有代碼相關的腳手架工具，直接生成基本的統一項。這樣一個工具的好處是可以直接一鍵完成許多基礎工作，并完成了底層的統一工作。

多頭維護

代碼腐化的一個很重要的因素是多頭維護，甚至是多代維護。一個公共項目，多個開發團隊都在維護，那就很難統一標準。初始版本有一個架構，然后換了一個架構，開發更是換了幾批。人多手雜說的就是這樣的情況。任何開發團隊接手一個舊項目時，其實都是有學習和適應的成本的。頻繁的變更開發人員帶來的壞處就是反復的人為制造這個成本，其次就是有幾率丟失之前的一部分標準和架構規劃。

架構沒有落地

代碼模塊的功能設計規劃，制定的標準，沒有詳細的落地。架構定了一套，開發沒有嚴格執行。每天寫代碼這么忙，架構只管架構，不管細節。開發每天擼代碼，只管功能，不管架構和代碼質量(這個質量不是指功能實現上的質量，而是說嚴格執行各項統一標準的程度)。甚至說，一個高層服務，不能調用同級服務，只能調用底層服務。因為開發的沒有嚴格執行，甚至加了數據庫連接，直接去取了數據庫，這樣的事一旦開了口子，就像黃河決堤，不可收拾了。所以，以上說的是架構的落地落實很重要，讓所有具體的開發參與者落實同一個標準。架構就需要落實相關的設計，相關的文檔，相應的執行檢查。現實的情況從來沒有靠文檔解決一切問題的，可它能解決80%的問題，另外就盡量減少開發人員的變動，以減小換人帶來的代碼腐化問題。

防止代碼腐化的建議：

代碼規范標準化，統一化治理

代碼的內部質量其實很難保證，規范執行也更多的靠人治，甚至個別標準化的東西，只能通過代碼層面去檢驗，無法通過測試或其他手段進行。另外，雖然有一些通行的默認標準，更多的標準是代碼的負責人自行確定的標準，完全根據喜好來，就像前面說的縮進的長度。好比是老媽和丈母娘都跑來你家里幫你打掃衛生，老媽喜歡把廚房里的鍋都一路洗好掛起來，丈母娘喜歡找一個櫥柜，都放在櫥柜里，你能怎么辦?沒關系，只要確定下一套標準，不要經常改就好了。

架構嚴格落地

像前面說的標準，特別是自定義的標準，都需要落地。***優先文檔，第二是團隊內部達成共識，第三是執行。

嚴格的codereview

防代碼的腐化執行是一個關鍵點，這個關鍵點就是codereview。在這個時間點，再次與開發強調標準的重要性，讓開發知曉執行，讓測試監督，讓架構嚴格檢查。對于不符合的，開發要再次去學習執行標準。

減少開發人員的變動

如果一個團隊內，原本標準就是統一的，團隊內實行敏捷開發，任何一個開發都可以替代其他開發工作，那么兩個人交換任務就沒有問題。如果團隊內都不統一，這個變動就會嚴重影響開發，代碼腐化的可能會變的很大。而團隊間，標準統一的可能性比在團隊內更難，要避免團隊間的項目移交才是***的方法。

代碼模塊架構Keep it Simple&Stupid，使用一眼就明白的架構

現實世界中，業務需求永遠的跑在技術需求前面，很可能架構相關的設計沒有文檔，沒有說明，一旦架構師不在，原來的開發換人了，導致原先的標準和設計無法繼續下去，一旦有交接，標準的丟失和架構的變化不可避免。這時，此條原則就能發揮作用。要使用傻瓜化的架構，就是任何一個新來的程序員，一眼就能看明白的架構。例如使用公司統一的項目代碼生成器，腳手架，生成統一的代碼結構，不需要程序員再投入代碼結構學習的成本。而且通用架構就意味著，后續的架構師接受原先設計的可能性大增。

分層的概念很早就提出來了，為什么MVC的概念會這么受歡迎?我覺得是因為它足夠傻瓜化。數據庫的架構結構中，定義repository，service接口，serviceImpl的實現等也成為了很通用性的設計。有一個挺經典的例子就是asp.net.MVC的程序組織架構三個文件夾：Controllers，Models，Views直接約定，并強調約定大于配置。只要是開發過這類程序的程序員，都知道從Controller看路徑和RestApi入口，Models看數據結構，View看Html視圖。就不需要額外的學習成本。Maven的標準目錄結構也是一個例子。(見上圖)

定期清理維護

如同像打掃房間一樣，一段時間不打掃，自然會有邊邊角角的臟東西出來。那么有沒有定期的去清理呢?還是不管他，每次看到地上的一團紙，都繞過，而不是去扔了?定期的清理維護不單是一個維護代碼的過程，更是一個重新梳理和統一標準的過程，讓現有的開發和架構，再次的達成一致，以提高戰斗力

防止代碼膨脹

微服務概念的提出后，很好的解決了一個問題，我們的一個代碼模塊應該寫多少大的問題?一個模糊的建議是一個Sprint能重寫的大小，如果更大，就應該要差分。有時候代碼的清理維護工作也要以這個原則來處理，不能出現過大的代碼模塊。因為過大的代碼模塊，首先帶來的是程序的復雜度，讓程序員理解起來要更多成本。其次，模塊內部的耦合度必然也提高了，增加了難度。這時，需要的是切分出一個新模塊出來。

總結

代碼腐化是程序開發的一個經典問題。代碼內部質量的降低，外部質量確可以被客戶接受。程序員經常想著，等業務沒那么忙的時候，做點清理，做點模塊局部的微重構，我的經驗告訴你，這些都是假的。如果定下了定期清理，定期檢查拆分，就必須立馬去做。做這些事的優先級要遠高于業務需求。 為什么呢?想象一個程序C++的printf，里面的代碼寫的非常的爛，變量命名都是p，m，k完全不能直觀理解含義，我們需要鄭重的去處理這個模塊的代碼腐化問題嗎?

其實不需要，因為printf模塊的代碼需求，就是把輸入的內容打印出來，永遠都是這樣，沒有任何新需求，沒有新需求就代表沒有程序員需要深入內部去改它的代碼，不需要改的代碼，我們是沒有動力去解決它的腐化問題的。有必要經常深入解決腐化問題的代碼，必然是業務需求很多，經常要變更的代碼。不要等到它已經腐化到代碼生命周期都快走到頭了，才想起來去維護清理它，要經常維修一下，才能更好的讓它發揮作用，是吧?一輛不打算開的老爺車，發動機壞了就壞了，一輛經常開的二手奔馳，定期維護少不了。