半熟前端

軟體工程師 / 台灣人 / 在前端的路上一邊探索其他領域的可能性

前端

如何 Code Review

前言

身為前端工程師,通常在整個團隊裡面會是最常發送 pull request 的人。為了讓自己的 PR 更容易被測試,以及讓 reviewer 更容易的 review,總結了一些注意事項。

pull request 的描述

  • 這個 pull request 的目的。例如:修正 layout、新增 feature、某個畫面的 style 等等
  • 記住每個公司的成員都可以看見 pull request ,所以確保 pull request 的敘述提供夠完整的資訊。
  • 明確地說明你想要怎樣的 feedback。
  • 使用 prefix 來說明你的 pull request 狀態。
  • 將需要看這個 code 的成員加入進來(可以使用 github 的 assign 功能)

提供 feedback

  • 如果你不同意 pull request 內的寫法,先停下來思考一下,為什麼你不同意。想清楚了再留下 comment
  • 用詢問代替命令。「為什麼你不採用這樣的寫法呢?」優於「不要這樣寫!」,先問問看對方的想法或是意見,說不定他們不那樣寫是有理由的,這時候就可以做適當的溝通與交流。
  • 解釋為什麼你覺得這些 code 需要被修改(不符合 style guide?不符合公司命名規範?沒有寫 test case?)
  • 提供更好的方法來改善目前的 code
  • 盡量避免具有攻擊性的評論。(e.g:這樣寫很白痴。)
  • 保持謙虛。
  • 盡量避免斷定。(別這樣子寫 code!)
  • 在線上溝通的時候,難免會有某些誤解產生。這個時候可以考慮面對面溝通。
  • 用個 emoji 來加強你的語氣,例如:good job 👋 👍。 需要修正哦👻(這好像有點嘲諷?

回應 feedback

  • 感謝那些願意幫你 code review 的人。
  • 對於任何不清楚的地方,發問就對了。
  • 如果這個 feedback 有被實作或是在某個 commit 裡面,提供連結給他。
  • 如果討論越來越複雜而且一直得不到結論,試著當面跟他溝通。

每個人

  • 必須理解大家都有不同的 coding 風格,而且寫程式總會有許多解法跟選擇,所以在討論的時候應該適當做權衡,並且充分解釋為什麼你覺得這樣比較好。
  • 用問的,不要用命令的。
  • 不要劃分責任(這是你寫的不關我的事、這部分是你要處理的)
  • 試著去理解一下作者的觀點和想法。

結論

雖然以上總結了那麼多點,不過我覺得圍繞的點還是在於是否為對方著想。你想看到怎樣的 pull request,從這個角度切入,或許會更有感觸也說不定。 畢竟如果出錯了,甚至是因為自己的疏忽,把 code 部署到 production 上了,還要再浪費整個團隊的時間重新找 bug,重新部署一次。