【Programming Style】新創公司不用做 Code Review？

如果你正處在一家軟體開發的新創公司，你如何定義你產品的 code 是「好的」？我常聽到大家說，只要產品 work，程式就是好的！如果事情這麼簡單，工作就容易多了。但事實其實相距甚遠。

大多數的工程師都知道 code review 的重要性，至少，他們是這麼認為的；然而大多數的團隊卻沒有定期去執行 code review。如果我們都知道它有多重要，為什麼沒有更多團隊這麼做呢？

原因是，大多數工程師害怕 code review 無法帶來足夠的好處，所以不值得費時費力去做；有些人認為整個執行程序老舊無趣且沒有人真正相信它；有些人則擔心 code review 往往以無謂的爭執收場，例如  function parameter 後面要不要接結尾空格之類的。

概括來看，之所以被忽略的原因有兩個，團隊沒有充分被教導為何他們該做 code review，以及對完整 review 所須具備的要件缺乏了解。所以接下來，讓我們來討論為什麼你的團隊應該確實的執行 code review。

1. 散播知識

一般來說，一個工程師僅負責系統中單一的核心架構，對其他部分的理解並不多。然而顯而易見的是，當越多人了解系統的不同部分，才越有保障。比方說可以降低團隊成員因生病、放假或離職的風險。另外，當團隊中的越多人了解其他成員的工作，可以幫助你在重要功能發佈的 deadline 前做更有效率的資源分配。

最後，當團隊成員對 codebase 的理解逐漸增加時，修 bug 的次數會跟著減少，團隊也可以更專注於產品開發。

2. 更好的 Code Quality

多一個幫你看、多個人幫你想，總會更好一些。為什麼這個功能要用這種方式執行？同樣的事情可以有更好的方式去做嗎？這個方法的規模好嗎？這樣夠安全嗎？ 我們是否已經寫了一個功能可以做到相同的事？

每個工程師都有不同的技能與專精，長期而言，有他們的共同參與可以省去你許多時間。

3. 分享式學習

工程師能自學的空間有限。透過 review 以及觀察其他工程師的做法，你可以獲得很多以前無法得到的新知識。對資淺的工程師來說，這會是個很好的機會去觀摩資深工程師不同的工作方式；另一方面，資深工程師也能利用他們多年來累積的經驗及智慧，為整個 codebase 帶來正面的影響。

4. 同儕壓力

承認吧！當你知道其他人將會檢查你的 code，你最好確保你有縮排，好好命名，而且不要寫一些不知為何就莫名做出來的神奇程式！

為什麼呢？因為你的同事多半是你尊重的人，你在乎他們的意見，而且你知道他們會評斷你的工作成果。但如果沒有 code review，這些促使你寫出好程式的誘因也就不存在，而你的 codebase 極有可能長成不受控制的蠻荒大西部。

5. 抓到 Bug

當然，在 code review 的過程中可以抓到許多 bugs，這對許多工程師來說或許可以徹底省去很多令人頭痛的問題。通常我們發現，早期的 code reviews 所抓到的 bug 可以堆的比天花板還高，但因為 code review，程式的水準會不斷進步，到了後期抓到的 bugs 數就會越來越少了。

要不要做 code review 的確是一個重大的取捨，而最常見的討論就是時間與品質的選擇。兩方都有許多忠誠的擁護者，但最重要的還是取決於你想怎麼做，以及你想從 code reviews 中獲得什麼。我建議，不要拘泥於過於細節的問題，例如       這一類的問題，而應該專注於邏輯與設計的概念。

另外一個議題是，我們該如何進行 code review？應該做 pre-commit 或是 post-commit reviews 嗎？我將會在下一篇文章討論這些問題。

不論你認為 code review 對你的團隊是否必要，我想每個人都會同意 two brains are better than one。所以馬上行動吧！現在就找到另一雙眼睛來檢視你的 code，然後等著享受這麼做帶給你的好處！