Fear, and loathing In KUSO pull request

Transcript

1. Fear, and loathing In KUSO PULL request
2. Workshop 以下のPRのレビュワーにアサインされた場合に、イラっとくるポイントをあげて みよう https://github.com/doilux/kusopr/pull/1
3. レビューの意義 INPUTとOUTPUTの整合性チェック ダブルチェック 異なる観点からのチェック
4. work is ... 設計書 実装 input output 作業者 INPUTとOUTPUTの整合性チェック
5. review is ... 設計書 実装 input output 作業者 レビュワー INPUTとOUTPUTの整合性チェック 設計通りに実装できているかチェック
6. ダブルチェック レビューしてみよう（疑似コードです） val pref_country_map = [ “埼玉”: “関東”, “千葉”: “関東”, “東京”: “関東”, “京都”: “関東”, “大阪”: “関西”, “兵庫”: “関西”, ]
7. ダブルチェック レビューしてみよう（疑似コードです） val pref_country_map = [ “埼玉”: “関東”, “千葉”: “関東”, “東京”: “関東”, “京都”: “関東”, <- おそらくコピペミス “大阪”: “関西”, “兵庫”: “関西”, ]
8. 異なる観点からのチェック レビューしてみよう（疑似コードです） val pref_jabanese_english_map = [ “栃木”　: “tochigi”, “埼玉”　: “saitama”, “茨城”　: “ibaragi”, “群馬”　: “gunma”, “千葉”　: “chiba”, “東京”　: “tokyo”, “神奈川”: “kanagawa”, ]
9. 異なる観点からのチェック レビューしてみよう（疑似コードです） val pref_jabanese_english_map = [ “栃木”　: “tochigi”, “埼玉”　: “saitama”, “茨城”　: “ibaragi”, <- ibaraki “群馬”　: “gunma”, “千葉”　: “chiba”, “東京”　: “tokyo”, “神奈川”: “kanagawa”, ] 東日本出身者のほうが気付くか も（実は、自分はずっとibaragi だとおもってましたorz
10. レビュー依頼の心得 WHO:誰に WHY:なぜ（なにを期待して） WHAT:何を HOW:どのようにチェックしてもらうか
11. レビューして欲しいのは設計？実装？ 設計ならクラス図やシーケンス図をレビューしたほうがよくない？ 実装なら、設計については合意している？ （レビュワーも設計を理解している？）
12. レビューして欲しいのは手順？変更箇所？ どちらにしろ、このコミットの切り方だと、どこまでがツールのアウトプットで どこが手を加えたところかわからない
13. 　知るか 　なぜ、リファクタリングでテストコードも変えたし なぜ、大事なファイルを修正したし（コミットメッセージはWhyやHowを）
14. まとめ • レビューで品質を高められるかどうかは、レビューの出し方次第 • レビューを活用して品質を担保するのは作業者の責任 • 誰に、何を期待して、何を、どのようにチェックしてもらうかを意識しよう