Code review對于軟件項目來說是一個經(jīng)常聽到的詞，大家都在強調(diào)質(zhì)量左移，Code review既是質(zhì)量的一道門禁辐脖，也是知識分享的一個很好途徑。那么如何保證review的質(zhì)量僵娃？
首先我們要在團隊的技術(shù)能力的不同階段采用不同的review策略概作。比如團隊穩(wěn)定，編碼規(guī)范掌握的比較好默怨，使用的語言也是熟悉的語言讯榕，那么可能review的重點就會放到業(yè)務(wù)邏輯方面；目前本人所參與的項目則采用此方式匙睹，團隊成員技術(shù)成熟愚屁，基于GO語言編碼業(yè)務(wù)，多人參與Sprint迭代一個用戶故事開發(fā)痕檬，若開發(fā)完成霎槐，則由用戶故事開發(fā)負責人進行review其他人實現(xiàn)該用戶故事的代碼，沒問題后提測梦谜，即Code Done的DOD包括code review通過丘跌。如果團隊新成立，還在磨合唁桩，可能編碼規(guī)范就需要多注意闭树；如果是團隊新?lián)Q了一門編程語言，那么語法本身可能也會是review的重點荒澡。如果是這種場景报辱，本人參與項目的做法是由架構(gòu)師組織團隊成員線下review會議，會議上架構(gòu)師說下項目代碼寫得優(yōu)雅的地方以及需要改進的地方单山。
在公司業(yè)務(wù)發(fā)展的不同階段也需要采用不同的review策略捏肢。比如To B的業(yè)務(wù)在穩(wěn)定推進，那么Code review可能需要更加仔細嚴格饥侵，保證質(zhì)量和代碼的可讀性可維護性鸵赫；但是如果是在互聯(lián)網(wǎng)行業(yè)，業(yè)務(wù)發(fā)展初期躏升，在快速試錯階段辩棒，那么Code review需要Technical leader去平衡review力度和業(yè)務(wù)交付的要求。
需要團隊里有開放的文化和心態(tài)膨疏，Code review有時會被團隊成員認為是挑毛病一睁，但是通過review達到團隊代碼層面的bug數(shù)越來越少，并且互相review也可以提升編碼能力佃却，逐漸讓大家意識到是代碼review是一個必不可少的質(zhì)量保證過程者吁，同時也是一個互相學習的過程。但是我們也要注意控制每次需要Review的代碼量饲帅。如果一次提交大量的代碼進行review复凳，幫助做Review的人一個是時間上很難一次性拿出這么多的時間瘤泪，另外一個是也很容易抓不到重點。同時提交代碼的人在commit note中應(yīng)該寫清楚提交代碼的目的：實現(xiàn)的是什么功能育八？做的是什么優(yōu)化对途？修改的是什么bug？這樣review的人才能有的放矢髓棋，清楚代碼改動的上下文实檀。
最后要讓Code Review變成一種習慣，工作中的一部分按声，那么就需要對Review者的時間有所保證膳犹，建議Sprint計劃會上團隊預(yù)估時的時候考慮到code review的時間，可以參考之前幾個迭代review的時間作為buffer預(yù)留在迭代中签则，這樣review才能作為一個日常任務(wù)被執(zhí)行镣奋，同時把code review作為用戶故事DoD的一部分。
文章來源如何做code review
