この文書はCode Health: Respectful Reviews == Useful Reviewsの翻訳です。
コードレビューはソフトウェアプロジェクトの品質改善のための役立つツールとして知られているが、一方、あいまいで、きつすぎると解釈されるコードレビューは好ましくない結果となりうる: 遅いレビュー、ブロッカーとなるレビュー、ネガティブな感情、他のコントリビューターや同僚に対するネガティブな認識など。
これらのティップスを用いてコードレビューを丁寧に解決することを考えてほしい。
レビューアーあるいはコードオーサーとして
-
○ 能力を仮定する。 コードオーサーの実装やレビューアーの推奨は君のとは異なるコンテクストを持つ立場から来ているのかもしれない。理解するために質問することから始めよう。
-
○ 根拠やコンテキストを提供しよう。 ベストプラクティスの文書や、スタイルガイド、デザインドキュメントなど。そうすることで、相手になぜそう考えるのかを理解するのを助け、メンターシップを与える。
-
○ どのようにコメントが解釈されるうるかを考慮しよう。 誇張やジョークや絵文字などが違ったふうに捉えられることに気をつけよう。
悪いコードオーサー:
僕は短い名前の方が好きなんだ。
ここを変えようとは思わない。
君が強制しない限りね。:)
いいコードオーサー:
ベストプラクティスは自明だったり一般的な語を除くように推奨している[^1]。
そのアドバイスとこのリクエストをどう調和をとるべきだろうか。
- ✗ 個人を批判する。 代わりに、コードを議論しよう。たとえ、コメントが人に関して書かれていたとしても（例、「君」といった語が使われている）、コードを改善するというゴールに集中しよう。
悪いレビューアー:
どうしてこのアプローチを使ったのか。
君は不要な複雑さを追加している。
いいレビューアー:
この並行モデルによって、はっきりとしたパフォーマンスの改善はないが、
システムの複雑性は増しているようにみえる。
- ✗ 不快な言葉を使う。 ネガティブな調子のコードレビューのコメントは役に立ちにくくなる。例えば、先行研究で、とてもネガティブなコメントはコードオーサーにとって57%で有益だと捉えられたが、より中立なコメントは79%も有益だと捉えられた。
レビューアーとして
- ○ はっきりとして行動を起こせるフィードバックを提供する。 もし、具体的なアドバイスができないのであれば、コードオーサーにどうしてその判断をしたのかを明らかにしてくれるようお願いするのもいい。
悪いレビューアー:
ここ分からない。
いいレビューアー:
これは最適化なのかな。もしそうなら、コメントを加えてくれる？
- ○ 小さなことであるということやオプショナルなコメントだということを明示的に表明する。
NitやOptionalから始めることで、コードオーサーはレビューアーの期待することを推し量ることができる。
コードオーサーとして
- ○ コードを明確にするか、フィードバックに対してレビューアーのコメントに答える。 それに失敗するとコードの改善を実装する能力が足りていないとみなされかねない。
悪いコードオーサー:
そういう場合もあるけど、ここでは違う。
いいコードオーサー:
なぜ実装がこうなっているかのコメントを追加した。
- ○ フィードバックに同意できないとき、君のアプローチの利点を説明しよう。 意見の一致をみないとき、Googleガイダンスの「コードレビューに関するコンフリクトの解消」に従ってほしい。