前言

身為前端工程師，通常在整個團隊裡面會是最常發送 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，重新部署一次。