關於pull request這檔事

之前寫過關於code review這檔事,那反過來說,關於發pull request這檔事呢?(或者說發patch也適用,以下就姑且都說PR吧,節省篇幅愛地球。)

Automattic的夥伴們都挺愛挑毛病修細節的,PR來回修個幾週才進、打掉重寫,或是要拆細重發等等多不勝數,所以以下也算是個人在敝公司發PR的生存守則:

  1. 單一目的
  2. 測試方法清楚簡單
  3. 迭代大於完美

繼續閱讀 “關於pull request這檔事"

關於Code review這檔事

說到code review這件事,相信這年頭凡是吃碼農這行飯的,多多少少已經成為工作的一部分了( 啥?貴公司沒在做這件事甚至反對這件事?塊陶啊~~~)

如果估狗『how to code review』、『code review guidelines』等關鍵字,很容易就可以找到許多不錯的參考文章,但很多都是超過十項的點檢表,我實在不擅長記憶這麼多項目,常常邊看邊忘,在腦內只留下了浪漫模糊的輪廓。

點檢表是非常有用的,特別是在初期對一個code base還很不熟悉的時候。例如咱家WordPress VIP code review guidelinesWordPress theme development checklist、這篇Kevin London的Code Review Best Practices也曾被轉載一陣。待對code base熟悉到一個程度以上後,記憶幾個好記的思考源作起點再從之延伸,對我來說比較容易掌握:

  1. 我了解整個patch / PR的目的嗎?
  2. 我知道該怎麼測試嗎?
  3. 每一行變更的意義我都完全了解嗎?
  4. 我們能做得更好嗎?

繼續閱讀 “關於Code review這檔事"