Skip to content

コードレビュー

This content is a draft and will not be included in production builds.

https://twitter.com/Linda_pp/status/1171416072894894086

Google のコードレビューガイド.レビューコメントに大事なのは

  • 優しく
  • 理由を説明する
  • なるべくどう変更したら良いかまで書く
  • 複雑なコードは口頭で説明させるだけでなくコード内にコメントを残させる(かコードを簡潔に直させる)

Google Engineering Practices Documentationが原本。日本語訳もある。

https://twitter.com/daiksy/status/1197023963446050816

ぼくはなんとなくわかるんだけど、コードレビューで自分がつらくなるのは、「問題対わたしたち」も「コードと人格は別」も充分わかっていて、かつその上でコードレビューの指摘内容により自分自身の無能感が浮き彫りになるということがあると思う。

レビューする側の億劫さについてはレビューする際の心理的障壁に書いた。観点はコードレビューの目的に書いた。

提出する立場では、Russ Coxがgolang-devの”What should we do with CLs generated by AI?”スレッドに投稿した文章を忘れてはいけない。

社会的な観点から言えば、コントリビューターがコードレビュー用に提出するコードは、偶然うまく動いたものではなく、事前に十分な自己レビューを行った高品質なコードであることが常に期待されています。むしろ、長期的な保守性や他者による理解可能性を考慮した上で、その問題を解くための最善のコードを提出することが求められます。 … 最終的にレビュー担当者の時間を費やす価値があると判断したバージョンのみを提出します。

これはOSSは技術よりもソフトスキルの重要度が高いにも関係している。

どのくらいの大きさなら許せるのかについてはPull Requestの適切な大きさも書いた。

上のようなことがレビューが爆速になる!レビュアーに優しいPull Requestの極意に全部書いてある。