我在上一篇文章 〈新創公司不用做 Code Review？看完這五個理由再決定吧！〉 裡，談到新創公司落實 code review 的好處。而在這篇文章，我想進一步解釋 post-commit 與 pre-commit code reviews 的不同之處，以及在你的工作和開發流程中該使用哪一種 code review 方式。
post-commit code reviews 是一種不會阻擋程式碼發佈的 review 方式，它發生在你的程式碼送出之後；pre-commit code reviews 則會自動阻擋，任何程式碼都必須先被 review 後才能發佈，在沒有 review 前，程式碼甚至不存在於版本控管系統中。
對於 pre-commit code reviews 來說，最大的反對聲浪在於，程式在尚未進入你的主要程式庫前，就必須要先花時間進行 review。然而，這個爭議顯然忽視了 pre-commit reviews 所帶來的好處：
- 一、鼓勵小量的 commits
假如你新增修改了大量的程式碼，然後才 commit 提交，這是一個錯誤的開發方式。對於程式庫的改動應該是短小、可讀且容易被理解的。
當我們推行 pre-commit reviews 時， 為了讓程式能快速地被 review，會誘使開發者每做完小幅度的更動就 commit 提交程式碼。相反的，如果採用 post-commit reviews，由於沒有任何機制可以阻止你發佈程式到正式站上，你就不會特別注意每次 commit 時你的程式更動規模有多麼巨大。
- 二、早期發現，早期治療
審查者可以幫助在你弄壞程式庫之前找到 bugs，並取得充裕的時候去處理，避免 bugs 在發佈到正式站後才被發現。
- 三、專注完美
你將有充份的動機去處理那些有問題的程式碼，否則你的程式碼將無法被發佈。但對於 post-commit reviews 而言，你經常會因為過於忙碌而無視於問題的存在。
- 四、更穩固的架構
當有問題的程式碼一旦提交到程式庫中，它將難以被根除。對於 pre-commit reviews，你可以在這些程式碼進入程式庫之前，確認它對程式庫的影響，而 post-commit reviews 則難以做到這點。
看到這裡，如果你已經傾向採用 pre-commit reviews，卻擔心目前的開發流程無法採行這種方式，放心，你還是可以隨時改成 post-commit reviews，雖然效果有限，但還是多少有些好處：
- 一、比較簡單
post-commit reviews 並不會阻擋任何程式進入你的程式庫，不需要對現行的開發流程做任何改變。
- 二、總比沒有好
雖然 pre-commit 比較有效，但 post-commit 至少會有另一雙眼睛幫忙看你的程式，聊勝於無。
如果你覺得建置 pre-commit reviews 對你的團隊來說是項大工程，你應該從 post-commit reviews 開始做起，然後隨著時間進展，再逐漸導向 pre-commit，你可以先試著採用 pre-commit 在比較重要的程式中，最後再全面導入。
上一篇文章闡述了為什麼應該進行 code reviews，這一篇我們則看到兩種不同的實行方式。無論你選擇哪一種，都要記得，早一點及經常 commit 你的程式碼，頻繁而小量的修改提交，比起一次提交大量的修改程式，來得容易被 review。
本文作者 David Shariff ，Richi 技術總監。他曾擔任 Yahoo! 前端工程師及網頁技術傳教士，也曾任職於趨勢科技擔任 UI 工程師；擁有豐富網路技術開發經驗，包含 HTML5, CSS3, JavaScript 以及 PHP 等。
如果你也是有理想有才能的 RD，我們正在尋找你的加入：https://richi.com/marketing/careers
（截圖來源：Amazon）
以下為 David Shariff 英文原稿：
Pre-Commit VS Post-Commit code reviews
In my last article, I discussed about the benefits of why your startup should be doing code reviews. In this post, I will explain what are the differences between post vs pre commit code reviews, and which one to use depending on your workflow / development process.
Typically, code reviews will be performed in one of two situations, known as post-commit and pre-commit. Post-commit reviews are referred to as “non-blocking”, and are done after your code has been deployed. Pre-commit reviews are “blocking” by nature, meaning the code needs to be reviewed before it can be deployed or even exists in your version control repository.
The biggest argument against pre-commit code reviews is the time it takes for code to be reviewed before it can become part of the main repository. However, this argument is short sighted without considering the distinct advantages that pre-commit review offers:
1.Small commits are encouraged. If you are making big commits then you are developing wrong. Changes to the repository should be short, readable and understandable. With pre-commit reviews, you are more incentivized to make smaller changes as they can be reviewed quicker. With post-commit reviews, nothing is blocking your work from going to production, so you tend to care less about the size of your commits.
2.Catch bugs before they exist. The code reviewer can find bugs before you break the main repository which gives you preemptive time to fix what might have occurred in production.
3.Focused attention on quality code. You become more motivated to respond and fix issues raised with your code, otherwise your code will not go to production. With post-commit reviews, you often just leave raised issues when you are too busy.
4.Stronger architecture. Once code is committed to the repository, it gets baked into the product and is often hard to remove. With pre-commit reviews, you can influence and suggest architecture changes before they become part of the product, something that is hard to change if you are doing post-commit reviews.
While pre-commit reviews are preferred, if you feel your development process can’t handle it, you can always revert to post-commit reviews. Although not as effective, post-commit reviewing still offers some benefits:
1.Easy to implement. Since post-commit code reviews are non-blocking, you do not need to modify your existing development process.
2.Better than nothing. Although pre-commit reviews are more effective, doing a post-commit review gives a second set of eyes on your code, its better than not doing any code review.
If you feel that implementing pre-commit reviews is too big a change, you should start with post-commit reviews and then gradually work your way to pre-commit. As time passes, you can try using pre-commit reviews for more important code changes, and then eventually make the full transition.
The previous article outlined why you should be doing code reviews, and today we looked at two ways that you can implement reviews. Whichever process you choose, remember to commit early and often, multiple small changes are easier to review than one gargantuan commit.
David Shariff, Technical Director, Richi
Programmer 改變了我們的世界。Programming 精進之路，是條漫長的修煉過程。你的 Programming Style 是什麼？歡迎投稿《TechOrange》 Programming Style 專欄，和大家分享你的軟體開發經驗，不管是程式開發的實作分享，或是軟體專案管理的真實案例，亦或是產品發展的心路歷程。 歡迎來信 [email protected]，讓世界知道，你如何埋首努力寫出準備改變世界的 Code。
