我為什麼要幫你查 Bug?
作為程式設計師，在我們的日常 Coding 中，或多或少會在程式碼中隱留一些 Bug，但這些 Bug 看似無傷大雅，那是否還有程式碼審查的必要性？
作者 | Sophie Alpert
譯者 | 樑蕊
責編 | 屠敏
出品 | CSDN（ID：CSDNNews）
以下為譯文：
最近一個朋友問我，為什麼做程式碼審查很有價值。大多數矽谷的科技公司都會對每一個變更進行程式碼審查，至少有兩組人盯著它看。在我之前的一項工作中，我們做了一段時間的程式碼審查（很少），然後一個來自 Google 的新員工加入了我們，鼓勵我們評審所有的程式碼——我們做到了。這是一個偉大的決定。
如果你正確的進行程式碼審查，它不應讓你感到繁瑣。你和你的審查者不是對手，你們在一起合作開發出最好的軟體。（重要的是不要把反饋當成是在針對你——即使你的程式碼需要修改，但這並不意味著你有問題。得到反饋是很正常的，這能幫助你成長！）
有些公司制定了複雜的規則，規定對於每一段程式碼需要多少人審查，對於誰負責每一段程式碼有嚴格的“所有者”。我從來沒有覺得這樣做是必要的。我更喜歡一個更加簡單的系統，其中唯一的規則是每段程式碼必須由一個人檢查。在實踐中，您仍然會向負責維護您所更改的特定程式碼的人傳送審查，但是最好不要有硬性要求。
下面是我認為程式碼審查之所以有價值的最重要的原因。有很多東西！
程式碼本身。程式碼審查中最明顯的價值通常體現在“捕捉 Bug”中。或者，如果你看的再深入一點，找出作者不知道的最佳實踐或潛規則的缺漏，在這些情況下，審查者可以通過響應實際的具體程式碼來幫助改進程式碼。
巨集觀層面的知識共享。當你審查別人的程式碼時，你會傾向於學習新的技術，這可以讓你在日後受益——反之亦然，如果有人在審查你的程式碼時提出了更好的方法。如果你可以學以致用，你將成長為一名工程師。
微觀層面的知識共享。或者，通過增加熟悉給定程式碼段的人員數量來減少“巴士係數”。
方向共享。與此相關的是，程式碼審查迫使你與團隊成員交流你正在做的事情，這有助於確保你不會在幾天或幾周內走向錯誤的方向，因為這會給他們一個機會進行回推。
交流練習。無論是在團隊內部還是團隊之外，清晰的溝通都是在工作中取得成功的最重要的技能之一。程式碼審查為你提供了一個清晰地練習寫作的機會，包括在描述更改的目的時以及在對更改進行反饋時。運氣好的話，當下次你需要寫一些“真正重要”的東西時，你會準備的更充分。
歷史記錄。根據我的經驗，當人們知道有人在閱讀他們的資訊時，他們傾向於寫更好的提交資訊。這在以後回顧舊的更改時通常很有用。
討論的問題。當你試圖就要進行的更改達成一致意見時，有時候很難用言語描述並在細節上達成一致，比如說，一個特定的演算法。通過一段程式碼進行交流可以更精確，因為程式碼往往是明確的。
團隊凝聚力。定期進行程式碼審查時，工作感覺更像是一個團隊一起工作，而不是每個人在各自的領域中工作。
閱讀練習。練習閱讀別人的程式碼可以幫助你記住如何讓自己的程式碼可讀性更強（從而更易於維護）。這會帶來更好的程式碼！
如果要我選的話，理由 2、5 和 6 對我來說可能是最有價值的。那你怎麼看呢？
原文：https://sophiebits.com/2018/12/25/why-review-code.html
本文為 CSDN 翻譯，如需轉載，請註明來源出處。
熱 文 推 薦
☞Java JDK 收費，Android 也坐不住了，程式設計師們該咋辦？
☞華為 2018 手機銷量破 2 億臺；全國首個 5G 地鐵站開通；iPhone 7/8 下架 | 極客頭條
print_r('點個好看吧！');
var_dump('點個好看吧！');
NSLog(@"點個好看吧！");
System.out.println("點個好看吧！");
console.log("點個好看吧！");
print("點個好看吧！");
printf("點個好看吧！\n");
cout << "點個好看吧！" << endl;
Console.WriteLine("點個好看吧！");
fmt.Println("點個好看吧！");
Response.Write("點個好看吧！");
alert("點個好看吧！")
echo "點個好看吧！"
點選“閱讀原文”，開啟 CSDN App 閱讀更貼心！