[[230778]]

寫(xiě)代碼如同打掃屋子，有句話(huà)叫一屋不掃何以?huà)咛煜隆Ｈ绻麊蝹€(gè)的一個(gè)模塊代碼都不能管好，如何成就一個(gè)完善的軟件系統(tǒng)?今天我們來(lái)說(shuō)說(shuō)，一個(gè)代碼模塊的代碼是如何一步步腐化變質(zhì)，到***程序員都不愿意去維護(hù)它，然后要么重構(gòu)，要么廢棄換新模塊的?

代碼是有一定的周期的，這個(gè)沒(méi)有錯(cuò)。為什么有的代碼跑上幾十年任然好用，而現(xiàn)在互聯(lián)網(wǎng)公司的很多代碼，每年都要做好幾次重構(gòu)?一個(gè)成立2年的互聯(lián)網(wǎng)公司，做一個(gè)支付系統(tǒng)，可以做了4-5代，每次重構(gòu)，這樣的代價(jià)有多大?如何才能讓原有的代碼生命周期更加長(zhǎng)，而不增加很多的學(xué)習(xí)維護(hù)成本，開(kāi)發(fā)一次使用更久呢?

大部分程序員是沒(méi)有很多機(jī)會(huì)從0開(kāi)始搭建一個(gè)新程序的，更多的時(shí)候是接手別人寫(xiě)的代碼。有代碼移交還好一點(diǎn)，往往因?yàn)楦鞣N因素，這些因素你懂的，沒(méi)有產(chǎn)品文檔，沒(méi)有設(shè)計(jì)文檔，沒(méi)有程序說(shuō)明，程序里可能連注釋都沒(méi)有。然后，程序員更新?lián)Q代又極其的快，互聯(lián)網(wǎng)時(shí)代，程序員在一個(gè)公司的平均年資也就1年多，程序就又被傳給下一任維護(hù)者。很大可能的情況是，最終到你手里的程序各種問(wèn)題，卻能實(shí)現(xiàn)基本的功能需求，但代碼內(nèi)部各種問(wèn)題讓程序員總有一個(gè)沖動(dòng)，重構(gòu)它。今天不想說(shuō)重構(gòu)的問(wèn)題，而是從根源角度分析，程序?yàn)槭裁磿?huì)變成這個(gè)樣子?

什么是程序的腐化?

什么是一個(gè)軟件的質(zhì)量?一個(gè)分類(lèi)標(biāo)準(zhǔn)是軟件外部質(zhì)量與軟件內(nèi)部質(zhì)量的統(tǒng)一，外部質(zhì)量是對(duì)外表現(xiàn)是否正常，內(nèi)部質(zhì)量是對(duì)后續(xù)開(kāi)發(fā)有沒(méi)有坑，就是我在這里說(shuō)的軟件有沒(méi)有腐化。內(nèi)部質(zhì)量標(biāo)準(zhǔn)有：可維護(hù)性，靈活性，可移植性，可重用性，可測(cè)試性，可理解性(摘錄自代碼大全)。不符合以上標(biāo)準(zhǔn)都可以稱(chēng)之為代碼腐化，形象的理解就是一個(gè)蘋(píng)果，從內(nèi)部開(kāi)始爛了，爛到原本應(yīng)該負(fù)責(zé)內(nèi)部代碼的程序員拒絕去維護(hù)了。

實(shí)際的代碼腐化的例子：

代碼混亂，沒(méi)有代碼規(guī)范不該連數(shù)據(jù)庫(kù)的模塊連了數(shù)據(jù)庫(kù)模塊間的調(diào)用混亂：模塊內(nèi)部的調(diào)用混亂，例如C#代碼已經(jīng)使用了EntityFramework，代碼中跳過(guò)EntityFramework，直接用數(shù)據(jù)庫(kù)連接修改數(shù)據(jù)。框架與其他不一致，不統(tǒng)一：有的包管理使用gradle管理，有的使用maven。有的后臺(tái)用.Net，有的用Node，有的用Java。

用了HttpClient，又使用Feign去連接其他應(yīng)用模塊有一些設(shè)計(jì)前后不一致：有的代碼使用了統(tǒng)一的錯(cuò)誤定義CommonException，有的用原生的Exception。微服務(wù)模塊，有resource層接口，定義訪(fǎng)問(wèn)的路徑，resource的Impl，service的接口提供具體的數(shù)據(jù)接口，serviceImpl提供具體數(shù)據(jù)獲取的實(shí)現(xiàn)。而在具體編碼時(shí)，將大量的業(yè)務(wù)邏輯寫(xiě)入了resource的實(shí)現(xiàn)中。

太復(fù)雜的抽象不能做方便的變更：一開(kāi)始設(shè)計(jì)的Job系統(tǒng)，上面是2-3張圖片，下面是動(dòng)態(tài)生成的問(wèn)題。代碼層面對(duì)于此設(shè)計(jì)做了很細(xì)致的抽象。突然產(chǎn)品提出了某一個(gè)Job的圖片有特別，要求顯示10張圖片，就對(duì)抽象的圖片部分做了if-else的處理……無(wú)用代碼，廢棄的接口沒(méi)有標(biāo)明

代碼腐化的原因

沒(méi)有代碼會(huì)是init commit的時(shí)候就開(kāi)始腐化的，腐化都是循序漸進(jìn)的，要一個(gè)過(guò)程。我總結(jié)了一些代碼腐化的原因：

• 沒(méi)有統(tǒng)一標(biāo)準(zhǔn)，或者沒(méi)有嚴(yán)格執(zhí)行
• 統(tǒng)一標(biāo)準(zhǔn)之代碼規(guī)范

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

統(tǒng)一標(biāo)準(zhǔn)之基礎(chǔ)規(guī)范

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

項(xiàng)目命名方式：com.(公司名).(開(kāi)發(fā)組名).(系統(tǒng)名).(模塊名)例如：com.omniprimeinc.cosmetic.application.server;Restful接口設(shè)計(jì)統(tǒng)一：大小寫(xiě)，命名方式，Body的***大小例如，Post接口是否可以加PathParameter和QueryParameter。Post接口是否可以不帶Body。其他配套功能的統(tǒng)一性：調(diào)用鏈，動(dòng)態(tài)配置管理，緩存，分布式事物數(shù)據(jù)庫(kù)的統(tǒng)一：統(tǒng)一數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)版本，是否可以使用存儲(chǔ)過(guò)程等。關(guān)于數(shù)據(jù)庫(kù)統(tǒng)一性不在這里展開(kāi)，這點(diǎn)也非常的重要。

統(tǒng)一規(guī)范之公司統(tǒng)一框架

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

多頭維護(hù)

代碼腐化的一個(gè)很重要的因素是多頭維護(hù)，甚至是多代維護(hù)。一個(gè)公共項(xiàng)目，多個(gè)開(kāi)發(fā)團(tuán)隊(duì)都在維護(hù)，那就很難統(tǒng)一標(biāo)準(zhǔn)。初始版本有一個(gè)架構(gòu)，然后換了一個(gè)架構(gòu)，開(kāi)發(fā)更是換了幾批。人多手雜說(shuō)的就是這樣的情況。任何開(kāi)發(fā)團(tuán)隊(duì)接手一個(gè)舊項(xiàng)目時(shí)，其實(shí)都是有學(xué)習(xí)和適應(yīng)的成本的。頻繁的變更開(kāi)發(fā)人員帶來(lái)的壞處就是反復(fù)的人為制造這個(gè)成本，其次就是有幾率丟失之前的一部分標(biāo)準(zhǔn)和架構(gòu)規(guī)劃。

架構(gòu)沒(méi)有落地

代碼模塊的功能設(shè)計(jì)規(guī)劃，制定的標(biāo)準(zhǔn)，沒(méi)有詳細(xì)的落地。架構(gòu)定了一套，開(kāi)發(fā)沒(méi)有嚴(yán)格執(zhí)行。每天寫(xiě)代碼這么忙，架構(gòu)只管架構(gòu)，不管細(xì)節(jié)。開(kāi)發(fā)每天擼代碼，只管功能，不管架構(gòu)和代碼質(zhì)量(這個(gè)質(zhì)量不是指功能實(shí)現(xiàn)上的質(zhì)量，而是說(shuō)嚴(yán)格執(zhí)行各項(xiàng)統(tǒng)一標(biāo)準(zhǔn)的程度)。甚至說(shuō)，一個(gè)高層服務(wù)，不能調(diào)用同級(jí)服務(wù)，只能調(diào)用底層服務(wù)。因?yàn)殚_(kāi)發(fā)的沒(méi)有嚴(yán)格執(zhí)行，甚至加了數(shù)據(jù)庫(kù)連接，直接去取了數(shù)據(jù)庫(kù)，這樣的事一旦開(kāi)了口子，就像黃河決堤，不可收拾了。所以，以上說(shuō)的是架構(gòu)的落地落實(shí)很重要，讓所有具體的開(kāi)發(fā)參與者落實(shí)同一個(gè)標(biāo)準(zhǔn)。架構(gòu)就需要落實(shí)相關(guān)的設(shè)計(jì)，相關(guān)的文檔，相應(yīng)的執(zhí)行檢查。現(xiàn)實(shí)的情況從來(lái)沒(méi)有靠文檔解決一切問(wèn)題的，可它能解決80%的問(wèn)題，另外就盡量減少開(kāi)發(fā)人員的變動(dòng)，以減小換人帶來(lái)的代碼腐化問(wèn)題。

防止代碼腐化的建議：

代碼規(guī)范標(biāo)準(zhǔn)化，統(tǒng)一化治理

代碼的內(nèi)部質(zhì)量其實(shí)很難保證，規(guī)范執(zhí)行也更多的靠人治，甚至個(gè)別標(biāo)準(zhǔn)化的東西，只能通過(guò)代碼層面去檢驗(yàn)，無(wú)法通過(guò)測(cè)試或其他手段進(jìn)行。另外，雖然有一些通行的默認(rèn)標(biāo)準(zhǔn)，更多的標(biāo)準(zhǔn)是代碼的負(fù)責(zé)人自行確定的標(biāo)準(zhǔn)，完全根據(jù)喜好來(lái)，就像前面說(shuō)的縮進(jìn)的長(zhǎng)度。好比是老媽和丈母娘都跑來(lái)你家里幫你打掃衛(wèi)生，老媽喜歡把廚房里的鍋都一路洗好掛起來(lái)，丈母娘喜歡找一個(gè)櫥柜，都放在櫥柜里，你能怎么辦?沒(méi)關(guān)系，只要確定下一套標(biāo)準(zhǔn)，不要經(jīng)常改就好了。

架構(gòu)嚴(yán)格落地

像前面說(shuō)的標(biāo)準(zhǔn)，特別是自定義的標(biāo)準(zhǔn)，都需要落地。***優(yōu)先文檔，第二是團(tuán)隊(duì)內(nèi)部達(dá)成共識(shí)，第三是執(zhí)行。

嚴(yán)格的codereview

防代碼的腐化執(zhí)行是一個(gè)關(guān)鍵點(diǎn)，這個(gè)關(guān)鍵點(diǎn)就是codereview。在這個(gè)時(shí)間點(diǎn)，再次與開(kāi)發(fā)強(qiáng)調(diào)標(biāo)準(zhǔn)的重要性，讓開(kāi)發(fā)知曉執(zhí)行，讓測(cè)試監(jiān)督，讓架構(gòu)嚴(yán)格檢查。對(duì)于不符合的，開(kāi)發(fā)要再次去學(xué)習(xí)執(zhí)行標(biāo)準(zhǔn)。

減少開(kāi)發(fā)人員的變動(dòng)

如果一個(gè)團(tuán)隊(duì)內(nèi)，原本標(biāo)準(zhǔn)就是統(tǒng)一的，團(tuán)隊(duì)內(nèi)實(shí)行敏捷開(kāi)發(fā)，任何一個(gè)開(kāi)發(fā)都可以替代其他開(kāi)發(fā)工作，那么兩個(gè)人交換任務(wù)就沒(méi)有問(wèn)題。如果團(tuán)隊(duì)內(nèi)都不統(tǒng)一，這個(gè)變動(dòng)就會(huì)嚴(yán)重影響開(kāi)發(fā)，代碼腐化的可能會(huì)變的很大。而團(tuán)隊(duì)間，標(biāo)準(zhǔn)統(tǒng)一的可能性比在團(tuán)隊(duì)內(nèi)更難，要避免團(tuán)隊(duì)間的項(xiàng)目移交才是***的方法。

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

現(xiàn)實(shí)世界中，業(yè)務(wù)需求永遠(yuǎn)的跑在技術(shù)需求前面，很可能架構(gòu)相關(guān)的設(shè)計(jì)沒(méi)有文檔，沒(méi)有說(shuō)明，一旦架構(gòu)師不在，原來(lái)的開(kāi)發(fā)換人了，導(dǎo)致原先的標(biāo)準(zhǔn)和設(shè)計(jì)無(wú)法繼續(xù)下去，一旦有交接，標(biāo)準(zhǔn)的丟失和架構(gòu)的變化不可避免。這時(shí)，此條原則就能發(fā)揮作用。要使用傻瓜化的架構(gòu)，就是任何一個(gè)新來(lái)的程序員，一眼就能看明白的架構(gòu)。例如使用公司統(tǒng)一的項(xiàng)目代碼生成器，腳手架，生成統(tǒng)一的代碼結(jié)構(gòu)，不需要程序員再投入代碼結(jié)構(gòu)學(xué)習(xí)的成本。而且通用架構(gòu)就意味著，后續(xù)的架構(gòu)師接受原先設(shè)計(jì)的可能性大增。

分層的概念很早就提出來(lái)了，為什么MVC的概念會(huì)這么受歡迎?我覺(jué)得是因?yàn)樗銐蛏倒匣?shù)據(jù)庫(kù)的架構(gòu)結(jié)構(gòu)中，定義repository，service接口，serviceImpl的實(shí)現(xiàn)等也成為了很通用性的設(shè)計(jì)。有一個(gè)挺經(jīng)典的例子就是asp.net.MVC的程序組織架構(gòu)三個(gè)文件夾：Controllers，Models，Views直接約定，并強(qiáng)調(diào)約定大于配置。只要是開(kāi)發(fā)過(guò)這類(lèi)程序的程序員，都知道從Controller看路徑和RestApi入口，Models看數(shù)據(jù)結(jié)構(gòu)，View看Html視圖。就不需要額外的學(xué)習(xí)成本。Maven的標(biāo)準(zhǔn)目錄結(jié)構(gòu)也是一個(gè)例子。(見(jiàn)上圖)

定期清理維護(hù)

如同像打掃房間一樣，一段時(shí)間不打掃，自然會(huì)有邊邊角角的臟東西出來(lái)。那么有沒(méi)有定期的去清理呢?還是不管他，每次看到地上的一團(tuán)紙，都繞過(guò)，而不是去扔了?定期的清理維護(hù)不單是一個(gè)維護(hù)代碼的過(guò)程，更是一個(gè)重新梳理和統(tǒng)一標(biāo)準(zhǔn)的過(guò)程，讓現(xiàn)有的開(kāi)發(fā)和架構(gòu)，再次的達(dá)成一致，以提高戰(zhàn)斗力

防止代碼膨脹

微服務(wù)概念的提出后，很好的解決了一個(gè)問(wèn)題，我們的一個(gè)代碼模塊應(yīng)該寫(xiě)多少大的問(wèn)題?一個(gè)模糊的建議是一個(gè)Sprint能重寫(xiě)的大小，如果更大，就應(yīng)該要差分。有時(shí)候代碼的清理維護(hù)工作也要以這個(gè)原則來(lái)處理，不能出現(xiàn)過(guò)大的代碼模塊。因?yàn)檫^(guò)大的代碼模塊，首先帶來(lái)的是程序的復(fù)雜度，讓程序員理解起來(lái)要更多成本。其次，模塊內(nèi)部的耦合度必然也提高了，增加了難度。這時(shí)，需要的是切分出一個(gè)新模塊出來(lái)。

總結(jié)

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

其實(shí)不需要，因?yàn)閜rintf模塊的代碼需求，就是把輸入的內(nèi)容打印出來(lái)，永遠(yuǎn)都是這樣，沒(méi)有任何新需求，沒(méi)有新需求就代表沒(méi)有程序員需要深入內(nèi)部去改它的代碼，不需要改的代碼，我們是沒(méi)有動(dòng)力去解決它的腐化問(wèn)題的。有必要經(jīng)常深入解決腐化問(wèn)題的代碼，必然是業(yè)務(wù)需求很多，經(jīng)常要變更的代碼。不要等到它已經(jīng)腐化到代碼生命周期都快走到頭了，才想起來(lái)去維護(hù)清理它，要經(jīng)常維修一下，才能更好的讓它發(fā)揮作用，是吧?一輛不打算開(kāi)的老爺車(chē)，發(fā)動(dòng)機(jī)壞了就壞了，一輛經(jīng)常開(kāi)的二手奔馳，定期維護(hù)少不了。