靜態測試之代碼評審的一些建議

　　Facebook產品經理王準的一些建議：

　　作為審查者，一定要讀懂diff;所有被接受的diff必須是在讀懂的前提下。做審查者的人要有“將來如果這些代碼線上出問題，我要幫助支持”的心理準備。

　　代碼審查應該被每個工程師當做工作的重要一部分。

　　應當在24小時內給回復，這應當變成共識。

　　感覺有問題的代碼，一定要在相應的行上做出評論 (inline comments)，以讓作者明白問題所在。

　　盡可能把對修改的所有意見一次性給出，減少來來回回的次數。比較復雜的建議審查者主動找代碼作者來進行線下溝通，達成一致。

　　一般的diff，來回次數不宜超過3次;如果超過3次，想想看，是不是diff 太大，太復雜了。

　　thoughtbot公司的代碼評審準則：

　　接受這樣的現實：很多編程上的主張都是一種個人觀點。應該討論它們的利與弊，提出你的傾向觀點，迅速地達成一種解決方案。

　　提問，而不是命令。(“把這個變量改成:user_id，你覺得如何?”)

　　請求給予說明。(“我不明白。你能解釋一下嗎?”)

　　避免代碼的歸屬之爭。(“我的”，“不是我的”，“你的”)

　　避免使用一些會被認為是有關人身特征的詞語。(“笨蛋”，“愚蠢”)要把所有人都看作是有魅力的、聰明的、善意的。

　　要明確。要記著并不是每個人都能理解你的意圖。

　　要謙虛。(“我不能確定——我們來分析一下。”)

　　不要用夸張修辭語。(“總是”，“從不”，“永遠”，“毫無…”)

　　不要諷刺。

　　展現真實的你。如果你不是幽默型的人，不喜歡使用一些表情符號或動畫gif圖，不要勉強。如果你是這種人，請自信的發揮。

　　如果有太多的“我不理解”或“另一種方案：”的評論，請專門針對這個人進行交流?？梢园涯銈兙€下的交流總結成一個帖子附在后面。

　　對審查者的建議表示感激。(“謝謝提醒。我會把它改正。”)

　　理解審查是對事不對人。審查的是你的代碼，而不是你。

　　解釋為什么代碼寫成這樣。(“因為xxx原因我才寫成這樣。如果我把這個類/文件/方法/變量改個名會更清晰些嗎?”)

　　整理所作的改動，在以后的迭代中重構它們。

　　在做修改的版本上注明代碼審查的鏈接。

　　push提交要基于最早的一輪反饋，并形成一個獨立的分支。等這個分支上的任務完全完成了再合并。這讓審查者能夠根據早先的反饋找到你的單獨的更新。

　　努力站在審查者的立場上理解。

　　爭取回復每個評論。

　　直到最后一個人退出登錄后再合并分支。

　　直到持續集成測試(TDDium, TravisCI,等)告訴你這個分支的測試套件通過后再合并分支。

原文轉自：http://blog.csdn.net/lenxer/article/details/8693558