コードレビューでやること

基本的には感謝

どんなおかしなパッチでも取り組んでくれたことには敬意を払うべきである

明確なメリットがある時以外は代替案を強制しない

所謂「重箱の隅」であったり、個人の嗜好になりがち。

1往復無駄なやりとりを増やすことになるのでやるメリットが無い。

ヒントあるいは「こういう方法もあるけど、そのままで良いッス」みたいなレベルで留めるべき

コードのスタイルや一般的なミスパターンについてはコードフォーマッターやlinter、コンパイラのエラー等を使う

人間はこのあたりをレビューしなくて良いものとした方が良い

それでも漏れるのであればツールの方を直す、あるいは別のツールを使うべき

コードレビューで設計の話題になった時点で負け

別の場所で事前にコミュニケーションをした上で設計は決定されているべきである

あるいは事前にデザインレビューみたいなフェイズを置く必要がある

あるいはペアプロとか。

意図が明確になっていないコードのレビューが来た時にはコードのレビューをしない

先に意図を明らかにするところからはじめる

そもそもそれが起きている時点でコミュニケーション不足のシグナルであるように思う

このへんはpull-requestのテンプレートを用意するなどして仕組みである程度サポートできる

テストがコケているものについてはレビューする必要はない

もちろん「なぜテストがコケているのかわからない時」は相談を受ける