團隊管理中的代碼評審
阿新 • • 發佈：2017-09-25
減少 分類 個人 小問題 意思 修改 自我 兩個 凝聚力 代碼評審在軟件項目管理中是經常組織的活動，通過代碼評審的工作也確實給我們的團隊帶來很多的益處，簡單談談代碼評審的感受，你們的團隊是否也在進行代碼評審(Code Review)的相關工作呢？
1.為什麽要組織代碼評審
組織代碼評審其主要目的是保障我們的代碼質量和軟件產品質量，其次是團隊的學習提高，共同的成長。可以是兩個方面的驅動，外在現實中的工作痛點和團隊內在戰鬥力提高的驅動。
<4>.團隊的代碼的維護性差、可讀性差、可重用性差、靈活性很差，使開發人員開發滯後，運維人員修復Bug很是困擾；
<5>.團隊代碼中存在潛在的高危Bug(性能問題代碼)，一般不會出問題，出現問題也不易排查，嚴重阻塞業務數據的流轉；
<6>.開發團隊交付的代碼質量差，給測試團隊帶來很多的時間的浪費，低效率操作，使開發團隊和測試團隊陷入疲憊狀態。 (2).團隊內在驅動： <1>.營造團隊學習氛圍。通過代碼評審，團隊成員彼此之間學習提高，如何才能寫出更高效、更易擴展、更易維護的代碼； <2>.促進團隊溝通交流。通過代碼評審，團隊可以有一個很好的溝通交流機會，提升溝通表達能力，提高團隊凝聚力；
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).代碼評審工作對團隊中每個人都有提高？團隊中每個人的感受也是不一樣的？
(1).實際工作中的痛點：
<1>.團隊開發的軟件質量越來越差，Bug居高不下，問題層出不窮；
<2>.團隊的代碼實現對應的業務功能，但卻漏洞百出，業務實現的合理性，程序邏輯的嚴密性，考慮不周；
<3>.團隊的代碼風格各異，同一邏輯的代碼結構，不同的人實現，其寫法各異，風格不統一，重復造輪子；
<4>.團隊的代碼的維護性差、可讀性差、可重用性差、靈活性很差，使開發人員開發滯後，運維人員修復Bug很是困擾；
<5>.團隊代碼中存在潛在的高危Bug(性能問題代碼)，一般不會出問題，出現問題也不易排查，嚴重阻塞業務數據的流轉；
<6>.開發團隊交付的代碼質量差，給測試團隊帶來很多的時間的浪費，低效率操作，使開發團隊和測試團隊陷入疲憊狀態。 (2).團隊內在驅動： <1>.營造團隊學習氛圍。通過代碼評審，團隊成員彼此之間學習提高，如何才能寫出更高效、更易擴展、更易維護的代碼； <2>.促進團隊溝通交流。通過代碼評審，團隊可以有一個很好的溝通交流機會，提升溝通表達能力，提高團隊凝聚力；
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).代碼評審工作對團隊中每個人都有提高？團隊中每個人的感受也是不一樣的？
團隊管理中的代碼評審