前言

進入倒數十天了，這一路走來也是不容易啊((汗

剩下來的十篇，我想要試著把焦點轉移，不再是那麼「硬」拼命 coding 學習，而是試著從一些「非 coding」的事情中學習，預計可能會是從心態、觀念、工具面著手。

雖說不會有那麼多硬知識與實戰，但我認為，要寫出「更好」的程式，這些東西其實也不可或缺。

今天，讓我們來聊聊 Code Review！

Code Review 是什麼？

簡單來說，就是團隊成員每當有程式修改，可以先送出 pull request 或 merge request，經過幾個人看過，改了哪些地方？有沒有不該 commit 的東西？寫法是否恰當等。

可能有人會直覺認為，這感覺就像在「檢查」其他人的 code，是不是要抓 bug 啊？

但事實上是，我們不是人體編譯器，沒辦法用肉眼掃過就知道哪裡會出 bug，尤其是 Javascript 這樣的弱型別語言，真的是難上加難，若真可以用看的找到 bug，那也算是功力深厚或者 bug 太明顯。

蛤那不抓 bug 我到底要看什麼？

Code Review 要看什麼？

以我自己 review 的經驗，以及我被 review 的經驗，我會濃縮成這三點：

• 目的明確性
• 程式碼合理性
• 複雜邏輯連動性

目的明確性

通常 PM 或 QA 都會用 Jira、Asana、Redmine 之類的專案管理工具，管理每一個 issue 或者 new feature，統稱為 ticket。

而這張 ticket 上面就會明確寫下，這次修改的範圍應該到哪裡。

因此，code review 應該先看的是，這張 ticket 標示的範圍、目的，是否跟程式修改吻合，有沒有改到範圍外，不然很容易看到 QA 跟 RD 在那邊吵架：

QA: 為什麼 ticket 上面只有寫要改 A，但是 B 卻壞掉了？
RD: 啊就 B 跟 A 很相關嘛! 不趁這次改我下次一定會忘記啊! 到時候你不是又要來找我!?
QA: 那你要先跟我講啊!
RD: 唉唷什麼都要講太麻煩了啦~

沒錯，就像上面的 Q 先生與 R 先生爭吵的，其實 RD 把相關的 code 一起修改是正確有效率的，但要嘛拆第二張 ticket 來處理，要嘛告訴 QA，要嘛在任何地方標註一下，如果只是自己默默改了，那麼真的是只能 #相信 #自信 #祈禱 來說服自己沒事了。

程式碼合理性

注意，這裡是寫「合理」，也就是這個「修改」合乎這個「目的」，就這樣而已。

有些功力比較深厚的，可以一眼看穿這段 code 有 bug，或者抓出比較沒效率的程式碼，遇到這種 reviewer 真的是上輩子有燒好香，因為被工程師擋下來，絕對比被 QA、PM 甚至客戶給抓到，還要好上千百倍!

但不是大家都那麼敏銳，因此最低的要求是合理，而不是「沒有 bug」，只要這次修改是針對問題點，有改到重點就可以了。

複雜邏輯連動性

程式愈寫愈大，總是會有一兩個地方，可能是一個模組、一個頁面，裡面的程式邏輯特別複雜，還牽涉到許多相關的程式。

由於程式不是只有自己在寫，每個人各有自己熟悉擅長的部份，有人熟悉登入邏輯，有人熟悉交易模組，有人熟悉資安，但沒有人能夠全部掌握。

因此當有人修改到一個這麼重要的位置時，牽一髮動全身，務必要請「全身」來好好 review 一下這個「一髮」，請所有會被這次修改影響的同事都看過，確定每個環節都有被照顧到。

Code Review 有哪些好處：

• 團隊一致性
• 觀摩學習
• 觀察團隊成員的習慣(?)

團隊一致性

很多時候其實我開發了一個新的元件，可以很有效處理需求，但團隊成員不知道，或者聽過但忘了，往往就繼續用舊的元件，導致同樣一個功能有許多人實作過，耗費每個人的時間精力，未來要 refactor 還要四處蒐集「失落的程式碼」。

這時候 code review 能發揮團隊共享的特性，也就是讓資訊在整個團隊中暢通對等，不會每個人都在自己造輪子(DRY)。提醒使用新的元件、規範甚至 coding style，都能夠讓整體溝通更有效，程式也更乾淨一致。

觀摩學習

code review 是一件很有趣的事情，雖然有些人會困擾著：

「蛤~我寫自己的 code 都忙不過來了，還要看別人的，哪來那麼多時間？」

但我們可以試著跳脫這種從「工作」出發的視角，而改用一種「觀摩」的視角。

就像學習做菜一樣，做菜其實是一種創作，荷包蛋可以有一百種作法，你有自己煎荷包蛋的方式，但也可以去觀摩其他人，他們是怎麼煎荷包蛋的？媽媽做的荷包蛋特別好吃，他的火侯、調味、順序是怎麼安排的？

Coding 也是一種創作，是的，不然為什麼叫做程式「設計」呢？那如果是創作，就意味著每個人寫出來的，肯定不盡相同，即便目的、功能是一樣的，我們仍然可以從「觀摩」的過程中，思考很多平常自己不會發現的事情：

• 他為什麼要用 Set 來儲存資料？用 Array 不行嗎？
• 他為什麼先做 A 再做 B？有什麼好處嗎？
• 他為什麼把一個功能拆成多個 function？不拆不行嗎？

當我們 code review 跳脫「為了工作」的視角，而是試著站在一個「為了觀摩」的視角，就有機會可以在其他人的程式碼中，發現自己沒想過的新世界。

觀察團隊成員的習慣

這點則是比較偏向團隊文化的部分，前面有說到，coding 也是一種創作，所以看別人的 code 就像在美術課看隔壁的同學畫出來的畫作一樣，往往可以看出一些屬於個人的特色。

比如有些人是很嚴謹的，修改變數、API 的時候，除了程式碼的部分，連文件、註解都會記得一起修改，一次到位從不囉嗦。

而有些人是很奔放的，有寫過的函式直接 copy 過來，註解也維持原汁原味，劈哩趴啦寫下來一大串，但也因此每次交付都非常迅速。

有些人則是很為團隊成員著想的，commit 訊息寫好寫滿，註解重點摘要，TODO、FIXME 該有的絕對有，不只下一個接手的人可以很快進入狀況，連幫他 code review 的人都可以很清楚知道意圖。

程式團隊其實也像籃球隊一樣，重點是放在贏球，所以每個人要盡可能站在擅長的位置上，發揮每個人的專長，才能夠讓團隊利益最大化，那當然第一步就是要清楚團隊成員的習慣囉！

結語

雖然花時間，但是 code review 無疑是快速學習，以及幫助團隊成長的一條道路，而且現在花時間，總比以後幫團隊成員收爛攤子，或者踩到 bug 痛不欲生好吧？搞不好最後其實是省時間呢！

你們公司有 code review 的制度嗎？如果沒有，你可以成為第一個！

仔細端詳著
畫裡絢爛的風采
寂靜地
寫下了生命的註解

參考資料

Google 程式碼審查指南