微信公眾號：當程序員以後關注可瞭解更多的開發技巧。
不知道你有沒有遇到這樣的場景，剛上線的一個功能，就出現了一個嚴重Bug，團隊週末集體加班吭哧吭哧的緊急處理，你們彼此抱怨不斷；你和老闆在給客戶演示產品新功能的的時候，突然系統崩潰了，在場的人一陣尷尬，急忙解釋一陣說這一塊還沒處理好。
遇到這種問題怎麼辦？是每個人只負責其中一個模塊麼，遇到問題出現問題的人處理嗎？不行，這樣忙的同學會忙死，閒的同學沒事兒做；那招一個測試同學呢？也不行，我們並沒有招聘的預算；
其實解決這個問題就是做好代碼質量管理，而代碼質量管理最重要的方法就是「Code Review」也就是代碼審查，為了簡單，下文我用CR簡寫。
代碼審查在維基百科解釋：
指對計算機源代碼系統化地審查，常用軟件同行評審的方式進行，其目的是在找出及修正在軟件開發初期未發現的錯誤，提升軟件質量及開發者的技術。簡單來說CR就是通過審查代碼來提升軟件質量和開發者技巧的方式。
為什麼要做 Code Review
那麼為什麼說CR能夠提升軟件質量和開發者技巧呢？以及為什麼我們要做CR？
首先對於初學者，CR是一種很好的學習方式，因為負責主要審查的人往往具有更豐富的經驗，知道哪些位置有坑，哪些寫法會造成問題，這樣可以最大限度的從代碼過程中提升個人技能。
尤其是那些資深的同事給新人進行指導講解的時候，效果可能不僅僅是知識代碼層面的，更是對以後工作態度，學習求真的深遠影響。要知道工作態度比知識和技能在工作中的影響佔比大的多。
記得我剛實習那會兒，就得到過公司技術VP餘弦大佬指點，工作中身邊的同事也對我的代碼進行了比較嚴格的審閱，那種一行一行的進行矯正，真是酸爽，那個時候能明顯感到自己在進步。
其次對於資深開發者，通過CR這種方式，自己能發現原來這種錯誤也容易出現啊，自己也需要注意下，避免掉坑。
另外有些開發過程有些功能自己使用的方法也不一定做到最好，有同事提出他的意見想法或者技巧時，你們就能碰撞出思維的火花，相互受益。
最後CR更好的利用了人性，就是更能發現別人的問題，這種相互的方式就能大大降低問題故障點。據統計正式的代碼審查發現缺陷率 60~65%，非正式不到50%，但也能發現很多問題。
通過這種方式我們在不斷交流討論過程中不僅提升了開發技巧更重要的是軟件質量也得到了保證。
怎麼做Code Review
說完了，CR是什麼（what），為什麼（why）要去做CR，先我們來聊聊怎麼做（how）CR。
通常情況主要是按照Github的Pull Request發起請求合併代碼的方式，通過指向某一個或多個負責合併的人來進行。
代碼審查一般會分為三類：正式的代碼審查、結對編程、以及輕量型的非正式代碼審查。
我們來看gitlab官方示例圖:
上面這個圖主要說了這個請求提交做了什麼事兒，我們的集成測試通過與否。
這裡面主要看到了我們代碼的變更情況，方便做代碼審查的人來進行閱讀。
我來說一個簡單的CR步驟流程：
1. 保證所有的單元測試和持續集成跑過，你這個提交做了什麼事（避免浪費別人理解時間）
2. 這個代碼至少有兩個及以上的團隊成員意見通過並且評論回覆LGTM（回覆任意的都行，有chrome插件可以檢測這個數量）
3. 最終進行合併代碼入庫（可以指定固定人合併也可以不指定）
解釋一下第二個步奏，保證有多人進行查看審閱，不僅可以保證代碼質量，並且可以保證不會出現單點的情況，比如你請假至少有同事熟悉你寫的代碼。這也是我們所說的高可用。
在做CR的過程中我們需要注意：
- 對代碼不對人，很多時候需要注意溝通的藝術，尤其是異步溝通的時候。
- 儘量統一風格，不過於糾結風格，保持寬容態度
保證這兩點我們就能開心愉快的討論技術問題，順便提高了軟件質量。
小結
本文最後讓我們來回顧一下文章的主要內容。
首先我們通過一個嚴重bug和系統崩潰引出瞭解決這兩個質量問題的方法--Code Review（代碼審查）。
然後我們解釋了Code Review可以提升代碼質量和團隊技能，利用好了這種方式及人性的特點，不僅對新手幫助巨大，也能幫助經驗豐富的老司機。
最後我們簡單說了Code Review的流程以及做這個過程注意點。
那麼我想請問下，你們團隊在做Code Review嗎？是怎麼做的呢？歡迎你給我留言，我們一起探討。
閱讀更多 濤哥聊Python 的文章
