iT邦幫忙

2021 iThome 鐵人賽

DAY 21
1
Modern Web

Javascript 從寫對到寫好系列 第 21

Day 21 - Code Review

前言

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

剩下來的十篇,我想要試著把焦點轉移,不再是那麼「硬」拼命 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 程式碼審查指南


上一篇
Day 20 - OR、AND 的活用方式與短路取值
下一篇
Day 22 - Formatter 與 Linter - 提升程式品質工具
系列文
Javascript 從寫對到寫好30

1 則留言

1
TD
iT邦新手 4 級 ‧ 2021-11-06 10:18:18

code review 是學習的好機會呢!

我要留言

立即登入留言