今天我們談一下開發團隊代碼質量如何做到管控與提升，我相信很多公司都會面臨這樣的問題，開發團隊大人員技術水平參差不齊，代碼寫的不夠規范，代碼掃描問題修改太過滯后，代碼庫管理每個團隊都不一致，偶爾還會合并丟失一些代碼，code review費人費時效率不高，開發任務的管理以及任務與代碼的可追溯問題，等等之類的問題，我們能否制定一套從設計到開發再到交付一整套的管控方案來幫助開發團隊管控代碼的質量？下來我就針對這些問題展開來談談我的想法。

舉個例子

比如說我們要增加代碼和任務之間的可追溯性，我們可能考慮采用git+jira關聯的方式對開發人員每筆提交在提交comment中增加jira編號，這是就是一個規范，但是規范落地如何檢查？開發人員如果忘記在comment中添加就會造成關聯失敗，那我們就要采用工具的方式幫助開發人員在提交時檢查comment是否符合規范。

比如說我們有制定編碼規范，也采用了sonar去掃描代碼的問題，但是這個方式的缺點是太過滯后，需要質量人員跟進去推動并且效果也不是很好，我們是否可以考慮前置檢查點幫助開發人員在代碼編寫和提交時能主動的發現問題，在代碼提交的時候發現規范問題可以直接進行解決再提交，我們可以考慮采用git加checkstyle、pmd、fingbug等工具插件，在代碼提交的時候進行規范檢測并且進行告警，這樣就可以很好的幫助開發人員及時的發現問題，并不是開發已經提交了再去sonar上檢查代碼規范來發現問題再事后的安排人員去解決，開發人員都有一個習慣，當功能開發好沒有問題后他們很少會去主動的修改與重構代碼，這樣就會導致遲遲不能推進，我們提前了檢查點幫助開發人員及時發現問題就可以更好的推行規范的落地。

因此我們要考慮提供一整套代碼質量管理的機制，應用在開發全生命周期中，并在關鍵的流程節點進行驗證，從而把控與提升代碼的質量。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

常見的問題及我的看法

靜態代碼掃描太滯后，推進吃力

我相信大多都會使用類似sonar這類的靜態代碼檢查工具來檢查代碼，這里我們不說工具的好壞，我們只說檢查問題的修復情況，我相信很多開發都會有一種習慣，在代碼寫完之后如果上線沒有問題的話他們是很少會去主動的優化代碼，即使你掃描結果告訴他他也會有各種理由推脫，當然我們可以通過管理的手段強制他們修改，比如說blocker、critical級別的必須全部改掉，其余的看情況修改，當然通過管理手段從上往下會有一定的效果，但是這些都是比較滯后的方式，我們能不能提前發現問題讓開發在功能開發過程中就把發現的問題改掉？

這個當然是可以的，我們可以利用代碼檢查的機制，在代碼開發中就讓開發去掃描發現問題，在代碼提交的時候去校驗如果有嚴重的禁止代碼提交。這樣一來我們就可以提前來發現并解決問題，這樣可能會帶來的是開發人員的排斥，開發人員都覺得自己代碼寫的沒有問題，所以這塊我們需要把控這個檢查規則的寬松度，我們可以結合公司的開發規范，整理不同級別的問題，通過先簡后嚴的方式，先把開發的習慣培養起來后再逐漸的提升嚴格度，這樣一來開發就有個適應期也比較好接受，比如說：我們通過checkstyle的規則模板定義，前期把一些無用導入包、命名不規范、導入包用*、system.out語句這類接受度高的作為error級別來推動開發適應從而培養這種良好的習慣。

團隊Code Review沒有跑起來或跑的太費事費力

在技術行業做了一定時間的人應該都知道code review是多么的重要，一可以促進團隊人員之間互相交流，二可以提升整體團隊的技術水平，學習優秀人員寫的代碼，幫助初級人員提升代碼編寫能力，所以code review還是強烈必須要做的，至于怎么做code review？我談一下我的想法和建議

比較常見的方式是定期團隊內組織全體人員進行集中式的code review，我比較推薦利用工具在線的操作方式來做code review，現在開源非常的火也可以參考學習開源團隊code review的方式，比如說github有pull request，gitlab有merge request，可以在這個合并代碼的節點上進行code review，這樣做的好處是第一比較開放，只要能看到合并代碼請求的都可以進行review，第二可以留下review記錄，互相的想法溝通和建議可以很好的留存下來并且可以通過UI的方式友好的展示出來，從而提升code review效率。

這個當然需要結合git flow的機制來協作完成。

代碼庫分支、版本管理不規范，合并丟代碼

團隊多了或團隊大了，每個人或多或少對git的管理與使用理解不一致，這樣就造成了分支、版本管理的混亂，這樣在版本代碼合并時就會產生很多沖突，我們可以指定一套規范性的東西，指導開發團隊進行分支、版本的管理，這里說到的是指導不是限制，要讓開發在可控的范圍內自由發揮。

可以參考git flow、github flow等，當然我們要統一一個工作流程推廣給開發團隊中。

前面我們說了用代碼合并來進行code review，這樣我們就要讓開發人員在每開發完一個任務的時候就要進行一次代碼合并，git是一個優秀的分布式代碼庫管理工具，我們利用git的分布式特性，以及靈活的流程機制來規范大家的使用。

例如：

一次迭代沖刺或一個版本對應一個develop-*分支和release-*，并且控制分支的push與merge權限，固定一個master分支并且控制master分支的權限，讓個人開發通過feature-{username|功能名稱}-*分支來進行功能開發，當一個任務或者一個功能開發完成進行一次develop-*分支的合并，這樣一來及可以code review也可以有序的管理分支上的代碼，當開發人員提交合并請求時發生了沖突就需要開發人員自己解決完沖突后再進行代碼合并請求，這樣一來版本分支上代碼是有序的。

以上可以定位分支約定。

具體的操作可以參考下面描述：

sprint開始時（需求確認后），從master創建develop分支，例如是develop-V1.2.0

開發人員從對應的develop分支創建自己的feature分支進行開發

如果master分支發生變更，需要從master分支合并到對應的develop分支、可以考慮定期合并一次

feature分支合并到對應的develop之前，需要從develop分支合并到feature分支（這個避免和其他人提交進行沖突，規范開發人員自己解決掉沖突后才能發起合并請求）

feature分支合并到對應的develop之后，發布到測試環境進行測試（測試環境直接使用對應的develop分支）

develop分支在測試環境測試通過之后，合并到對應的release分支并發布到預發布環境（UAT）進行測試

release分支在預發布環境（UAT）驗證通過后，合并到master分支并發布到生產環境進行驗證

發布到生產環境后從master分支構建對應的版本tag

可同時支持多個sprint的并行。

代碼提交備注寫的很難懂甚至很隨意

代碼的提交備注非常重要，尤其是在合并代碼時產生沖突，第一時間肯定是根據提交日期去看本次提交做了什么修改，如果說備注隨便填寫，或者有些都沒有填這樣在回頭來看的時候，及時是提交本人他也不能第一時間看出具體做了哪些修改，因此我覺得作為一個開發人員提交備注寫的清晰明了是一件必備的職業素養，至于一些不按照規范的技術人員我們也可以要求他們按照規范必須填寫。

那如何做到對備注填寫的質量把控呢？我們可以通過版本管理工具在提交代碼時進行提交備注檢測，比如說對長度的限制，至少要15個字符，或者對格式做一些驗證，必須包含任務編號之類，這樣一來就可以有效的控制代碼提交備注的質量以及可讀性。

我們現在常用的git就有hook機制可以提供在代碼提交前后做一些鉤子，利用鉤子來控制允許提交或者拒絕提交，比如說git的pre-commit和commit-msg

開發人員的任務管理與提交代碼沒有關聯，無法查看某個任務具體提交了哪些代碼

優秀的開發人員主動性都是很好的，主動性對開發來說也是非常重要的職業素養，不要讓人催促你來完成任務，自己要學會主動找任務去做主動想如何優化與提升，所以時間任務管理是非常重要的，我任務開發人員都應該具備自己的時間任務管理能力，無論用什么工具只要能管理跟蹤好自己的任務就是不錯的人員。

公司一般都有任務管理工具，有的用禪道、有的用jira，現在用jira的相對多一些，jira的功能豐富也可以促進團隊進行敏捷的任務管理，我們可以通過打通任務管理工具和代碼版本工具，讓代碼提交的時候通過任務編號產生關聯，從而可以在任務中看到代碼修改的片段。

這里我用jira+git舉個例子，比如說我們利用jira做scrum的敏捷管理，在制定好epic、story、task、subtask后，可以通過scrum模型的管理手段，在開發過程中通過插件、圖標的數據來分析是否有風險？那個人的任務delay？那個人的任務制定還可以再進行拆分？等，從而盡早的做出調整來控制整個迭代周期按時完成。利用git提交的備注寫入jira編號，通過jira和git的插件打通任務與提交代碼的關聯，這樣一來我們就可以很好的看到任務執行過程數據與具體改動了哪些代碼，從而提升開發效率。

統一管理校驗規則版本，由簡到嚴循序漸進的方式提升代碼質量

我們上面說到的利用了checkstyle來驗證代碼風格，通過git hook來控制提交備注的規范，這些都需要自定義一些腳本，這些腳本也應該利用git進行有效的管理，我們能力能做到統一的調整了規則與腳本，開發過程中的應用立即使用最新的驗證規則？還有git hooks的腳本是在開發機器本地運行的，這樣就帶來了一個問題如何讓開發去安裝腳本呢？叫他們手動安裝？寫個bat或shell腳本讓開發執行一次？

我覺得更好的方式是對開發透明在他們不知覺的時候已經悄悄的安裝，我們可以利用git對規則與腳本的版本進行管理，利用nginx可以通過http方式直接訪問規則與腳本文件，通過自定義maven plugin在代碼build的時候驗證開發機器上是否已經安裝，如果沒有就給它自動安裝與自動更新。

這樣我們只要修改了規則與腳本后進行版本發布，開發機就會自動的更新下來從而可以立即生效。

開發團隊技術氛圍低沉

很多公司開發團隊一味的滿頭苦干，很容易忽視團隊內的技術分享，再加上團隊內人員進進出出有一些正能量的人當然也有一些負能量的人，這都是常事，但是不管怎樣我相信做技術的人都愿意提升自己的技術能力，不管是工作中實踐學習還是說參加沙龍或者論壇，都是很好的學習渠道，人的精力也是比較有限不可能關注很多面，通過團隊內的技術分享，把每個人擅長的部分分享給大家，互相學習來提升凝聚力和團隊整體的技術水平，這樣長期以來我相信團隊內的技術氛圍肯定不會差。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

總結

以上就是我對代碼質量管理與提升方面的經驗與思考，里面涉及到很多東西，有流程的制定、工具的協作、工具的打通、規范的制定等，因此這是一個系統性的方案，希望可以利用一整套代碼質量管理的流程，在關鍵的流程節點來把控代碼的質量，形成閉環，希望可以幫助有需要的人，如果有更好的建議也希望大家多提意見進行補充，沒有完美的方式，只有找到適合的可落地的就是好的。