本文作者 David Shariff 目前於 Richi 擔任技術總監。他曾擔任 Yahoo! 前端工程師及網頁技術傳教士，也曾任職於趨勢科技擔任 UI 工程師；擁有豐富網路技術開發經驗，包含 HTML5, CSS3, JavaScript 以及 PHP 等。Contact us：https://richi.com/marketing/careers
如果你正處在一家軟體開發的新創公司，你如何定義你產品的 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，然後等著享受這麼做帶給你的好處！
- 延伸閱讀
【Programming Style】既然 Code Review 這麼重要，那應該要選 Pre-Commit 還是 Post-Commit 呢？
（圖片來源：Sebastian Bergmann, CC Licensed）
以下為 David Shariff 英文原稿：
Top 5 Reasons Why Your Software Engineers Need To Be Doing Code Review
When your startup is developing software, how do you define what is “good” code for your product? Often, I hear people say that the product “works”, so everything must be good under the hood, but the reality is far from it.
Most engineers know that the code review process is important one, or at least they think it is, but many teams still don’t hold these reviews regularly. If we know that these reviews are important, why aren’t more teams doing this ?
Many engineers fear that there are not enough benefits to make it worthwhile doing, some say the process enforces an archaic style of programming that nobody really believes in or that the review process just ends up in stupid debates about issues such as a trailing space after a function parameter.
The importance of code review is overlooked for 2 reasons; no education to the team about why they should be doing it, and a lack of understanding on what constitutes a good review. So why should your team be doing code reviews ?
1. Spreading knowledge
Usually, an engineer is responsible for a single core competency of the system, and has little to no knowledge about what is going on elsewhere. It’s obvious the more people that know about different parts of the system, the better protected you are. You mitigate against risk if a team member is sick, takes vacation or leaves the company. By having multiple people familiar with what each other is doing, you can load balance your resources during critical release deadlines. The increased knowledge of the codebase by all team members reduces the need for bug fixing, and increases the focus on product development.
2. Better code quality
Two sets of eyes are better than one. Two brains are better than one. You will often find that his generates discussions about why a certain feature was implemented in a certain way. Is there a better or more performant way to do the same thing? Will this method scale well? Is it secure enough? Have we already implemented a function that does the same thing? Every engineer has a different skill set, having their input will save you time in the long run.
3. Shared Learning
There is only so much an engineer can learn by themselves. By reviewing and looking at what other engineers are doing, you can gain a lot of new knowledge you might not of had before. It’s a good chance for junior engineers to learn how seniors are doing things differently, and for seniors to influence the codebase based on their years of wisdom and experience.
4. Social Peer Pressure
When you know someone else is going to look at your code, you better damn make sure you add indentation, good naming / organization, and don’t do magical things. Why? Your co workers are people you respect, and their opinions matter to you, you know they are going to judge your work. If there is no code review, the incentive to write better code is gone, and you are opening up your codebase to the wild wild west.
5. Bug Finding
Of course, during the course of a code review bugs are going to be caught. This is a good thing that might save you a lot of headaches further down the line. Usually, I found earlier code reviews tend to bubble up a lot of bugs, but reviews held further down the line tend not to catch as many, because the coding level / standard has kept improving since earlier reviews.
There is always a trade off when deciding whether or not to do code reviews for your team, the usual argument always boils down to time vs quality. There are plenty of arguments on both sides, but a lot depends on how and what you are looking for in the code reviews. I suggest, instead of focusing on microscopic issues such as does the parentheses have a space before it, you focus on logic and design concepts.
One more issue to consider will be how to conduct a code review? Should you be doing pre-commit or post-commit reviews? These questions are part of a larger discussion that I will cover in my next post.
Whether or not you deem code review necessary for your team, I think everyone would be in agreement that two brains are better than one. Start immediately, go and find a second pair of eyes this second to look at your code and enjoy the benefits that come with it!
David Shariff, Technical Director, Richi
Programmer 改變了我們的世界。Programming 精進之路，是條漫長的修煉過程。你的 Programming Style 是什麼？歡迎投稿《TechOrange》 Programming Style 專欄，和大家分享你的軟體開發經驗，不管是程式開發的實作分享，或是軟體專案管理的真實案例，亦或是產品發展的心路歷程。 歡迎來信 [email protected]，讓世界知道，你如何埋首努力寫出準備改變世界的 Code。
