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

舉個例子

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

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

因此我們要考慮提供一整套代碼質(zhì)量管理的機制，應(yīng)用在開發(fā)全生命周期中，并在關(guān)鍵的流程節(jié)點進行驗證，從而把控與提升代碼的質(zhì)量。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

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

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

常見的問題及我的看法

靜態(tài)代碼掃描太滯后，推進吃力

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

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

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

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

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

這個當(dāng)然需要結(jié)合git flow的機制來協(xié)作完成。

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

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

可以參考git flow、github flow等，當(dāng)然我們要統(tǒng)一一個工作流程推廣給開發(fā)團隊中。

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

例如：

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

以上可以定位分支約定。

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

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

開發(fā)人員從對應(yīng)的develop分支創(chuàng)建自己的feature分支進行開發(fā)

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

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

feature分支合并到對應(yīng)的develop之后，發(fā)布到測試環(huán)境進行測試（測試環(huán)境直接使用對應(yīng)的develop分支）

develop分支在測試環(huán)境測試通過之后，合并到對應(yīng)的release分支并發(fā)布到預(yù)發(fā)布環(huán)境（UAT）進行測試

release分支在預(yù)發(fā)布環(huán)境（UAT）驗證通過后，合并到master分支并發(fā)布到生產(chǎn)環(huán)境進行驗證

發(fā)布到生產(chǎn)環(huán)境后從master分支構(gòu)建對應(yīng)的版本tag

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

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

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

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

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

開發(fā)人員的任務(wù)管理與提交代碼沒有關(guān)聯(lián)，無法查看某個任務(wù)具體提交了哪些代碼

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

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

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

統(tǒng)一管理校驗規(guī)則版本，由簡到嚴循序漸進的方式提升代碼質(zhì)量

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

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

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

開發(fā)團隊技術(shù)氛圍低沉

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

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

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

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

總結(jié)

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