團隊管理中的代碼評審

代碼評審在軟件項目管理中是常常組織的活動，經過代碼評審的工做也確實給咱們的團隊帶來不少的益處，簡單談談代碼評審的感覺，大家的團隊是否也在進行代碼評審(Code Review)的相關工做呢？

1.爲何要組織代碼評審

組織代碼評審其主要目的是保障咱們的代碼質量和軟件產品質量，其次是團隊的學習提升，共同的成長。能夠是兩個方面的驅動，外在現實中的工做痛點和團隊內在戰鬥力提升的驅動。 

(1).實際工做中的痛點：
<1>.團隊開發的軟件質量愈來愈差，Bug居高不下，問題層出不窮；
<2>.團隊的代碼實現對應的業務功能，但卻漏洞百出，業務實現的合理性，程序邏輯的嚴密性，考慮不周；
<3>.團隊的代碼風格各異，同一邏輯的代碼結構，不一樣的人實現，其寫法各異，風格不統一，重複造輪子；
<4>.團隊的代碼的維護性差、可讀性差、可重用性差、靈活性不好，使開發人員開發滯後，運維人員修復Bug非常困擾；
<5>.團隊代碼中存在潛在的高危Bug(性能問題代碼)，通常不會出問題，出現問題也不易排查，嚴重阻塞業務數據的流轉；
<6>.開發團隊交付的代碼質量差，給測試團隊帶來不少的時間的浪費，低效率操做，使開發團隊和測試團隊陷入疲憊狀態。

(2).團隊內在驅動：

<1>.營造團隊學習氛圍。經過代碼評審，團隊成員彼此之間學習提升，如何才能寫出更高效、更易擴展、更易維護的代碼；

<2>.促進團隊溝通交流。經過代碼評審，團隊能夠有一個很好的溝通交流機會，提高溝通表達能力，提升團隊凝聚力；

<3>.促進團隊成長提升。經過代碼評審，團隊的總體戰鬥力都獲得提升，不斷的迭代強化下，團隊能夠交付高品質的軟件產品。

 

正是基於工做中的痛點和團隊內在的驅動，團隊才組織代碼評審，旨在提升軟件質量和團隊戰鬥力。

經過代碼評審，由一行行高性能代碼，一個個優良方法，一個個高內聚低耦合模塊，一個個層次抽離的業務，整個系統質量的提高，由小積大，不斷的持續改進，讓咱們的編碼規範成爲一種編程習慣。

經過代碼評審事項的組織，團隊成員的編碼水平不斷提升，在平時的代碼中就能夠規避掉一些很基本的錯誤，減小Bug的產生，同時不斷的優化咱們的代碼，團隊中每個成員都獲得提升，可能在其中你是學習者，可能在其中你是輔導者、引導者，都將是對我的和團隊能力的提升。

2.代碼評審事項評價

(1).好的地方：(正是解決上面提升的痛點和內在驅動)
<1>.代碼評審，能夠發現潛在的問題，作到風險提早控制；
<2>.代碼評審，能夠統一編碼風格，促使團隊造成良好的編碼習慣；
<3>.代碼評審，促進團隊溝通交流、互相學習、改善團隊氛圍、提升團隊凝聚力；

<4>.代碼評審，對於提高我的能力和團隊能力有很大的幫助，使團隊戰鬥力提升；
<5>.代碼評審，能夠節省開發和維護成本(易讀、可維護、可擴展的代碼)、測試成本(代碼交付質量高)。

(2).很差的地方：

<1>.代碼評審，暫用團隊太多時間，過多的討論問題細節，影響正常工做的進行且發現沒有成效；

<2>.代碼評審，不是爲了提高代碼質量、軟件質量的目的，而是變成了相關指責、挑剔對方寫的代碼；

<3>.代碼評審，審查會議團隊很活躍，審查會議後沒有跟蹤記錄，沒有可供數據分析的記錄，沒有提煉性的產出。

<4>.代碼評審，浮於形式，沒有任何的獎懲機制作支撐，作好作壞都同樣，不能提升團隊總體實力和交付軟件的質量。

 

3.代碼評審注意事項

針對代碼評審中存在很差的地方，爲了很好的組織代碼評審，讓團隊的代碼評審工做真的見成效，須要注意如下事項：

(1).作好時間把控

代碼評審必須作好時間把控，一是爲了保證咱們的會議高效性，一是爲了避免影響團隊的其餘工做的進行，通常控制在30-60分鐘。

對於代碼評審中的爭議問題，短期內不能給出好方案的，由會議紀要人記錄下來，待會議後相關人員討論，造成方案下次會議宣貫你們。

(2).調整團隊心態

宣貫告知團隊，組織代碼評審的目的和意義，讓團隊成員擺正心態，具備良好的包容氛圍、虛心學習請教的氛圍。

團隊幫你改進代碼，幫你優化你的程序和代碼寫法，使你提升應該感激；做爲問題提出者，能很好的正確引導同事也是我的能力的提升；做爲活動的參與者，在審查他人代碼的同時，既是一個自我檢視的過程也是一個學習提升的過程。

(3).作好會議紀要

爲了讓咱們的活動更好的執行下去，須要作好相關事項的紀要。由代碼評審會議的紀要人，將審查會議上被審查人的發現的不符合團隊代碼規範的地方進行記錄，以及在審查會議中有爭議的問題進行記錄，供之後進行下次代碼評審會議的跟蹤和之後數據分析的評級。

對於代碼評審出的問題，具備團隊同性的問題和解決方案，能夠整理出來添加到團隊的代碼規範中，一點點積累規避基礎性的問題。

(4).良好獎懲措施

爲了更好調動團隊積極性和代碼評審的成效性，這個可選的原則是，創建良好的獎懲措施。

對於在評審會議評審出的有問題的代碼，在下次評審會議時，檢視其未作修改或在新的評審中原來的問題仍是出現，給予記過，進行小小的懲罰；對於在評審會議積極發現問題代碼和提供建議比較多的團隊成員，給予獎勵，累計一迭代週期後，根據每一個人的記佳最多的，進行小小的獎勵。

 

4.代碼評審方案執行

代碼評審主要是提升交付軟件的軟件質量和提高團隊戰鬥力，其具體的方案也不拘一格，可根據團隊的具體狀況制定一個適合本團隊的代碼評審方案。

不要讓代碼評審變成團隊工做的負擔，不要變成阻礙團隊作事的屏障，不要讓代碼評審達不到預期的成效，反而低效率運做，這些都是團隊所不須要，若是真的是這種狀態團隊就須要好好檢視一下，是咱們沒有采用正確的方式來組織代碼評審，仍是確實代碼評審不適合對團隊的成長，估計是咱們的代碼評審的方式方法不對佔很大成份，那就要思考如何讓代碼評審工做達到甚至超過預期的效果。

 

(1).代碼評審規範文檔
要進行代碼評審的工做，必需要有一個審覈的指標和標準，代碼規範算是其中之一。代碼規範，是團隊接受的、承認的、持續改進優化的，是團隊都遵照的執行的標準。代碼規範可使團隊代碼的風格更加統一，能夠規避掉一些常見的問題。

若是在評審會議中對某些問題有爭議，可參照標準來作衡量，減小沒必要要的爭論，浪費時間；

若是代碼規範的標準不合理，聽取建議，確實認定不合理，及時改進，知會團隊相關人員；

若是代碼規範中並未說起的相關標準未，及時追加到代碼規範，讓代碼規範標準更豐富。

若是如今有一份還算不錯的代碼規範，那就應用與團隊，在不斷的代碼評審會議中，發現共性的問題，添枝加葉，不斷的豐富起來；

若是如今尚未一份合格的代碼規範，可讓團隊成員，每一個人提供4-5個代碼規範的標準寫到報事貼上，填錄完畢將建議信息收集整理進行彙總分類，團隊根據分類後的數據，討論某一點是否能夠加入咱們的代碼規範(或是借鑑他人的代碼規範，把適合本企業的代碼規範相關點整理到代碼規範中)。

 

代碼規範標準，不斷的迭代豐富起來，咱們的代碼規範愈來愈能規避各類潛行的小問題，一些常規Bug和難以理解、難以維護的代碼將在每一個人的改進中，逐步減小，代碼質量，產品質量也獲得提升，團隊總體水平也能到提升，團隊的戰鬥力獲得提升。

(2).代碼評審組織形式
<1>.肯定審查週期

爲保證團隊的高效和代碼評審確實能夠爲咱們的產品質量提升帶來的意義，建議代碼評審執行週期爲一週，具體在一週的某一天某個時間段，團隊可自行協商，能夠逐步調整時間，確實保證代碼評審的高效性，不要有太多的阻礙的因素和多任務處理並行，不要老是調整就好。

<2>.肯定參與人員

老大參與：爲確保初次審查活動的帶動性，老大參與仍是必須的，顯示對於這項工做的重視。

項目組成員參與：建議沒有緊急任務處理的團隊成員均可以參與，這是一個你們溝通交流學習提升的過程。

指定審查會議主持人：主要是根據被審查人提交的相關代碼和腳本進行整理，控制審查會議的時間和效率。

指定審查會議紀要人：主要是針對審查會議中的被審查人須要改進的代碼問題、團隊疑問質疑點、可提煉的共性規則進行紀要。

若是是團隊多項目小組任務並行的話，能夠分別小組內部組織也能夠團隊成員一塊兒，參與成員也不要太多，效果不是很明顯，小組多的話，小組間能夠相互學習和參照對比。

<3>.肯定審查內容
一週一迭代的代碼評審的審查內容是：審查週期內提交的相關代碼和數據庫腳本。

主要審查其代碼和數據庫腳本，有無違犯代碼規範和需改進地方，有無明顯的業務漏洞、邏輯漏洞以及是否存在性能問題。

其中本次代碼評審要審查的總代碼數和總存儲過程數，以及審查的總人員數，可根據團隊具體的狀況和會議的時間來控制。
<4>.肯定審查形式

A.審查會議前，通知相關參與人，指定主持人和紀要人，被審查人提交審查相關代碼和數據腳本。

其中主持人和紀要人，能夠由團隊成員輪值(提升團隊參與積極性)，也可固定安排由某人來處理。

B.由主持人就此次會議作簡要概述，而後後被審查展現講解本身的代碼，簡要概述這段代碼的功能，團隊一塊兒審查提交人代碼。

主持人概述：團隊第幾回代碼評審，本次被審查人是哪幾個，審查的代碼數和腳本數，上次遺留疑問解決宣貫，上次審查的執行確認。

被審查人概述：這個段代碼的功能，代碼的層次關係，對團隊成員有疑問的業務和技術寫法問題，作闡明講解。

C.針對被審查人存在的問題作討論，肯定是否有問題，並由會議紀要人作相關內容的紀要。

紀要人主要紀要：代碼和腳本的編寫跟團隊代碼規範、有問題的業務漏洞和邏輯漏洞以及存在性能問題、爭議無解的問題。

D.主持人引導被審查人的相關審查的推動，最後彙總這次代碼評審審查人數，每一個人的審查出的問題數，總問題數，作好紀要。

<5>.肯定獎懲措施
爲提升參與度和代碼評審的成效，制定代碼評審的獎懲制度，可由團隊成員你們協商肯定，要執行哪些懲罰和獎勵。團隊達成一致，團隊承認，共同遵照。

越多越好，越好玩越好，越有意思越好，你們積極參與提供建議。能夠是物質的，能夠是娛樂性的建議。
針對提出須要改進，未作改進的小小懲罰一下，娛樂一下；針對累計代碼評審週期，問題較少的，給與獎勵；爲團隊其餘成員代碼指出代碼問題比較多的，提供問題指導的，給予獎勵。

（如：一次代碼評審每人25分，一個月彙總一次，懲罰在每次審查時進行，獎勵在彙總時進行，懲罰給你們賣水果、唱一首歌、表演個節目等等）

 

5.代碼評審成效

代碼評審工做不須要咱們一次作的很到位，必需要作到A\B\C等等，重在逐步的改善，有所成效的提升。

代碼評審工做執行必定週期後，須要咱們檢視一下代碼評審工做是否真的能夠促進咱們的代碼質量和產品質量，團隊表決。

須要思考問題以及問題相關數據：

(1).代碼評審工做對咱們的目的有沒有推動做用？

(2).代碼評審工做對咱們的Bug的減小有沒有推進做用？

(3).代碼評審工做對咱們的代碼不規範的地方在審查中愈來愈少？

(4).代碼評審工做對咱們的團隊總體的戰鬥力有沒有促進做用？

(5).代碼評審工做對團隊中每一個人都有提升？團隊中每一個人的感覺也是不同的？