很多書都在強調 code review 的重要性。在我們的軟體部門剛開始成立，並沒有 code review。這個狀況持續了幾年，一直到前年，我才開始認真思考，不做 code review 真的對嗎? 於是我們從那個時候開始逐步推動 code review。

在沒有 code review 的時代，有兩件事情讓我印象深刻。第一件事情已經七、八年了，有一個週末，我們因為程式在下一週初要 release，想當然爾，工作是做不完地。所以我決定週末來加班。那時候我自詡應該當規劃者，所以平常是不寫程式碼地。可是真的來不及了，所以我得跳下來自己幹。沒想到那個週末，當我打開 project 的程式碼一看，我快嚇傻了。一個函式長達一千多行，眼睛東瞄西瞄看到的是許許多多重複的程式碼。這個該怎麼改呢? 到最後就是能頭痛醫頭腳痛醫腳，可想而知，那一個週末沒有什麼好下場了。第二件事發生在三年前左右，我們一個產品內的某一個 service，在屢次的進測，總是領到最多的紅牌。最後在產品被追殺的階段，我們發現那一個 service 無法收斂了。這時候我們開始投人進去那一個 service 進行 code review。不看不會怕，看了之後才知道多可怕。那一個 service 竟然高達一萬四千多行。可怕的是，這一萬四千多行在同一個檔案。是地! 一個 service 就一個檔案。最厲害的地方是，這個 service 破了之前的一千多行記錄，有一個函式高達三千多行。最後那一個 service 只能靠硬測的方式讓他自然地收斂。然後在後面安排 refactor。Refactor 後剩下八九千行，當然也拆了不少的檔案。可以看出來原來的作品中重複的程式碼有多嚴重。我們稱這種大函式叫："吾碼一以貫之"，這種一個函式殺到底的寫作方式，對於寫的人來說當然過癮，不用想太多次該怎麼擺變數，想一次就可以用 "很久"。但是對於看的人來說，實在是痛苦至極，看到第三頁的時候，已經不記得這個變數什麼時後宣告、什麼時候改值。諷刺的是一個函式不能太長這件事，在公司的 coding rule 當中是有提到地，為什麼還會看到這樣的事情出現？問題就在於事情沒有人去看，就容易歪掉。

這種事情就是這樣，開始總是最難地。前年開始推 code review 的時候，第一個遇到的難題就是人力的問題。這其實是一個弔詭的問題，本來寫 code 寫得很用力的團隊，突然要 "插" 一件 "本該做的事"，卻變成當時團隊多出來的事情。於是我只能動用手上所有的資源幫忙 review。然後因為遇到大家的時間不容易湊在一起，所以也請成員架上 Reviewboard 來協助分散式 code review。然後先是一個團隊持續地看到 review 活動，然後是另一個團隊的重要修改也開始 review。最讓人驚艷的是去今年初，已經有一個團隊將 Pre-commit review 自動化架好了 (用 Git + Gerrit + Jenkins)。只要 commit code，系統會自動驗證可否 build，然後會寄出 review request 給設定好的人。所以現在信箱一天會收到將近十封的 review request (說實在，加上 build 成功的訊息，一天信箱會被灌入 3, 40 封信，很快就會爆了 XD)。這樣的自動化，最有趣的地方在於讓你的 code 沒有被 review 過就不能夠 commit。因此現在對那個團隊而言，已經不是 optional, 而是 must。所以 review 活動就會被持續執行。而現在也會發現，因為 code review 的工作被拉出來，組長的工作裡頭自然會加入此項 task，所以比較不會像剛開始一樣覺得根本排不進去。

那麼到底這樣強推 review 有沒有什麼效果呢? 說句老實話，如果你期待 code review 可以大量減少 bug 數量，是比較不切實際地。但是他對於防範 non-trivial 的 bug，尤其是架構性問題、易維護問題、後續加新功能的 side effect 的防範，是有比較大的效果。另一個重點是，因為強制 code review，你可以在無形中強迫 member 去看到其他人被要求了哪些東西，下次他自己寫的時候就不容易重複同樣的錯誤。另外，自己寫的東西有人在看的時候就會比較小心一點，這些都是無形的效果。

現在開始有團隊在導入 scrum 了，在該團隊中更增加了 peer 的 code review。不再單純是上對下的 review。我覺得這樣做又有更進一步的效果，那就是懂 code 的人更多了，對於未來 task 的相互支援，也會變得比較有可能性了。這是我們在 code review 開始前享受不到地。

所以 code review 重要嗎? 非常重要。你們開始做了嗎?