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

舉個(gè)例子

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

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

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

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

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

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

常見的問題及我的看法

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

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

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

團(tuán)隊(duì)Code Review沒有跑起來(lái)或跑的太費(fèi)事費(fèi)力

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

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

這個(gè)當(dāng)然需要結(jié)合git flow的機(jī)制來(lái)協(xié)作完成。

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

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

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

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

例如：

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

以上可以定位分支約定。

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

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

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

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

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

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

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

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

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

可同時(shí)支持多個(gè)sprint的并行。

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

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

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

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

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

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

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

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

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

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

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

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

開發(fā)團(tuán)隊(duì)技術(shù)氛圍低沉

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

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

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

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

總結(jié)

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