背景

本文討論的代碼質(zhì)量指的是代碼本身的質(zhì)量，包括復雜度、重復率、代碼風(fēng)格等要素。代碼是團隊的共同財產(chǎn)，代碼質(zhì)量是團隊技術(shù)水平和管理水平的直接體現。

代碼質(zhì)量下降通常會(huì )自成因果，導致惡性循環(huán)：

• 破窗效應：在爛代碼上繼續生產(chǎn)爛代碼的心理負擔小很多
• 傳染性：爛代碼傳遞著(zhù)一種不在意質(zhì)量，只看業(yè)務(wù)成果的負面信息，會(huì )傷害團隊的技術(shù)熱情和工作氛圍，導致更多爛代碼出現

本文會(huì )分析代碼質(zhì)量下降的內在機制，并分享在代碼質(zhì)量管控方面的一些實(shí)踐經(jīng)驗。

熵增定律與代碼質(zhì)量

熵增定律告訴我們，一個(gè)封閉系統總是趨向于熵增，也就是系統的無(wú)序程度只會(huì )不斷增加。

對于軟件項目來(lái)說(shuō)，代碼質(zhì)量代表著(zhù)系統的有序程度，爛代碼增加就是系統無(wú)序性上升的體現。在無(wú)外力影響的情況下，爛代碼只會(huì )原來(lái)越多。

為了維持系統有序，需要外界向系統不斷輸入能量。對于代碼質(zhì)量，我們需要主動(dòng)投入資源，來(lái)有意識地抑制爛代碼越來(lái)越多的自然趨勢。

經(jīng)典循環(huán)

爛代碼產(chǎn)生的常見(jiàn)原因是業(yè)務(wù)壓力大，導致沒(méi)有時(shí)間或意愿講究代碼質(zhì)量。因為向業(yè)務(wù)壓力妥協(xié)而生產(chǎn)爛代碼之后，開(kāi)發(fā)效率會(huì )隨之下降，導致業(yè)務(wù)壓力更大，形成一種典型的惡性循環(huán)。

為了應對業(yè)務(wù)壓力，常見(jiàn)的做法就是向項目中增加人力，但是單純地增加人力的話(huà)，會(huì )因為風(fēng)格不一致、溝通成本上升等原因導致?tīng)€代碼更多。

要遏制這種惡性循環(huán)，需要多管齊下，主動(dòng)對代碼質(zhì)量進(jìn)行管控，并且持續進(jìn)行技術(shù)升級，系統性地解決問(wèn)題。

不過(guò)質(zhì)量管控和技術(shù)升級需要長(cháng)期投入才能產(chǎn)生效果。通常情況下人們還是傾向于通過(guò)增加人力快速地解決業(yè)務(wù)壓力的問(wèn)題，而忽略了對于代碼質(zhì)量的負面影響，導致代碼質(zhì)量越來(lái)越差。

四個(gè)階段

我把代碼質(zhì)量管控通常需要經(jīng)歷的四個(gè)階段，稱(chēng)之為“四個(gè)現代化”：

• 規范化 - 建立代碼規范與Code Review制度
• 自動(dòng)化 - 使用工具自動(dòng)檢查代碼質(zhì)量
• 流程化 - 將代碼質(zhì)量檢查與代碼流動(dòng)過(guò)程綁定
• 中心化 - 以團隊整體為視角，集中管理代碼規范，并實(shí)現質(zhì)量狀況透明化

階段一：規范化

保障代碼質(zhì)量的基礎是建立團隊的代碼規范，通常包括：

• 風(fēng)格規范 - 縮進(jìn)、換行、大小寫(xiě)等風(fēng)格問(wèn)題
• 實(shí)踐規范 - 規避一些常見(jiàn)的隱患，或者針對特定問(wèn)題的最佳實(shí)踐
• 業(yè)務(wù)規范 - 與業(yè)務(wù)有關(guān)的特殊要求，比如文案中的關(guān)鍵詞

團隊的代碼規范通常以文檔的形式存在，供新人們學(xué)習。但文檔這種形式常見(jiàn)的情況就是新人看過(guò)之后就不再回顧了，也很難對實(shí)際寫(xiě)代碼形成真正的約束。

在規范的基礎上，要通過(guò)Code Review將規范落地。Code Review中大家可以對代碼質(zhì)量問(wèn)題進(jìn)行交流，并且相互監督，形成團隊重視代碼的習慣。

關(guān)于Code Review可以參考另一篇文章：Code Review體系與團隊文化

階段二：自動(dòng)化

自動(dòng)化是指在代碼規范的基礎上，使用自動(dòng)化工具進(jìn)行質(zhì)量檢查，通常包括：

• 代碼規范檢查 - 包括風(fēng)格規范、實(shí)踐規范、業(yè)務(wù)規范
• 重復率 - 重復出現的代碼區塊占比，通常要求在5%以下
• 復雜度 - 總行數，模塊大小，循環(huán)復雜度等
• 檢查覆蓋度 - 經(jīng)過(guò)檢查的行數占代碼庫總行數的比例

自動(dòng)化質(zhì)量檢查可以覆蓋多數常見(jiàn)問(wèn)題，能夠提升開(kāi)發(fā)效率，也可以降低人工Code Review的成本。

自動(dòng)化檢查工具的規則集與代碼規范直接對應。通過(guò)編輯器插件，在寫(xiě)代碼的時(shí)候直接給出檢查結果。到這個(gè)階段，團隊的代碼規范文檔已經(jīng)不再需要陳述各種細節，開(kāi)發(fā)者可以直接通過(guò)查看自動(dòng)化工具的規則集來(lái)了解代碼規范。

階段三：流程化

流程化的意思是將自動(dòng)化代碼質(zhì)量檢查和Code Review與代碼流動(dòng)的過(guò)程綁定，從而保證所有上線(xiàn)的代碼都經(jīng)過(guò)機器與人工多個(gè)環(huán)節的檢查。

代碼流動(dòng)過(guò)程：

執行自動(dòng)化代碼質(zhì)量檢查的時(shí)機：

• 編輯時(shí) - 使用編輯器插件，實(shí)時(shí)運行質(zhì)量檢查
• 構建時(shí) - 在本地或者開(kāi)發(fā)機的構建腳本中運行質(zhì)量檢查
• 提交時(shí) - 利用Git Hooks，提交代碼或者生成Pull Request時(shí)運行質(zhì)量檢查
• 發(fā)布時(shí) - 在發(fā)布腳本中再做一次質(zhì)量檢查，通常與自動(dòng)化測試放在一起

質(zhì)量檢查與代碼流動(dòng)綁定后的效果：

除了人工的Code Review之外，各個(gè)環(huán)節的代碼質(zhì)量檢查都是機器自動(dòng)運行的，不會(huì )給開(kāi)發(fā)者帶來(lái)額外的成本。

階段四：中心化

當團隊規模越來(lái)越大，項目越來(lái)越多時(shí)，代碼質(zhì)量管控就會(huì )面臨以下問(wèn)題：

• 不同項目使用的代碼規范不一樣
• 部分項目由于放松要求，沒(méi)有接入質(zhì)量檢查，或者存在大量未修復的缺陷
• 無(wú)法從團隊整體層面上體現各個(gè)項目的質(zhì)量狀況對比

為了應對以上問(wèn)題，需要建設中心化的代碼質(zhì)量管控體系，要點(diǎn)包括：

• 代碼規范統一管理。使用Git或者NPM包管理自動(dòng)化代碼質(zhì)量檢查的規則集，自動(dòng)安裝，不在本地寫(xiě)規則。一個(gè)團隊、一類(lèi)項目、一套規則。
• 使用統一的持續集成服務(wù)。質(zhì)量檢查不通過(guò)的項目不能上線(xiàn)。
• 建立代碼質(zhì)量評分制度。讓項目與項目之間能夠橫向對比，項目自身能夠縱向對比，并且進(jìn)行匯總反饋。

總結

在面臨業(yè)務(wù)壓力時(shí)，人們通常會(huì )傾向于通過(guò)增加人力來(lái)緩解業(yè)務(wù)壓力。但從系統整體的角度來(lái)看，人力增加會(huì )造成代碼質(zhì)量變差，開(kāi)發(fā)效率下降，從而再度增大業(yè)務(wù)壓力。這種代碼質(zhì)量越來(lái)越差的循環(huán)，是熵增定律在軟件工程領(lǐng)域的生動(dòng)體現。

為了抑制這種循環(huán)，我們需要有意識地投入資源來(lái)建設代碼質(zhì)量的管控體系。這個(gè)過(guò)程分為四個(gè)階段：規范化，自動(dòng)化，流程化，中心化。每個(gè)階段都有不同關(guān)注的要點(diǎn)。

原文轉自：https://xiaozhuanlan.com/topic/1527938406