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

舉個(gè)例子

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

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

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

常見(jiàn)的問(wèn)題及我的看法

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

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

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

團(tuán)隊(duì)Code Review沒(méi)有跑起來(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)秀人員寫(xiě)的代碼，幫助初級(jí)人員提升代碼編寫(xiě)能力，所以code review還是強(qiáng)烈必須要做的，至于怎么做code review？我談一下我的想法和建議

比較常見(jiàn)的方式是定期團(tuán)隊(duì)內(nèi)組織全體人員進(jìn)行集中式的code review，我比較推薦利用工具在線(xiàn)的操作方式來(lái)做code review，現(xiàn)在開(kāi)源非常的火也可以參考學(xué)習(xí)開(kāi)源團(tuán)隊(duì)code review的方式，比如說(shuō)github有pull request，gitlab有merge request，可以在這個(gè)合并代碼的節(jié)點(diǎn)上進(jìn)行code review，這樣做的好處是第一比較開(kāi)放，只要能看到合并代碼請(qǐng)求的都可以進(jìn)行review，第二可以留下review記錄，互相的想法溝通和建議可以很好的留存下來(lái)并且可以通過(guò)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)開(kāi)發(fā)團(tuán)隊(duì)進(jìn)行分支、版本的管理，這里說(shuō)到的是指導(dǎo)不是限制，要讓開(kāi)發(fā)在可控的范圍內(nèi)自由發(fā)揮。

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

前面我們說(shuō)了用代碼合并來(lái)進(jìn)行code review，這樣我們就要讓開(kāi)發(fā)人員在每開(kāi)發(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è)人開(kāi)發(fā)通過(guò)feature-{username|功能名稱(chēng)}-*分支來(lái)進(jìn)行功能開(kāi)發(fā)，當(dāng)一個(gè)任務(wù)或者一個(gè)功能開(kāi)發(fā)完成進(jìn)行一次develop-*分支的合并，這樣一來(lái)就可以code review也可以有序的管理分支上的代碼，當(dāng)開(kāi)發(fā)人員提交合并請(qǐng)求時(shí)發(fā)生了沖突就需要開(kāi)發(fā)人員自己解決完沖突后再進(jìn)行代碼合并請(qǐng)求，這樣一來(lái)版本分支上代碼是有序的。

以上可以定位分支約定。

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

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

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

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

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

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

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

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

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

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

代碼提交備注寫(xiě)的很難懂甚至很隨意

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

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

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

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

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

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

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

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

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

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

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

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

很多公司開(kāi)發(fā)團(tuán)隊(duì)一味的滿(mǎn)頭苦干，很容易忽視團(tuán)隊(duì)內(nèi)的技術(shù)分享，再加上團(tuán)隊(duì)內(nèi)人員進(jìn)進(jìn)出出有一些正能量的人當(dāng)然也有一些負(fù)能量的人，這都是常事，但是不管怎樣我相信做技術(shù)的人都愿意提升自己的技術(shù)能力，不管是工作中實(shí)踐學(xué)習(xí)還是說(shuō)參加沙龍或者論壇，都是很好的學(xué)習(xí)渠道，人的精力也是比較有限不可能關(guān)注很多面，通過(guò)團(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ì)差。

總結(jié)

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

source: //ningyu1.github.io/20190307/111-code-quality-management.html

喜歡，在看