コードレビューにコメントを書く方法
まとめ
親切であること。 議論すること。 明確な解決策を提示する方法、または問題だけを指摘し、作成者に解決策を選択させる方法の２つを適切に使用する。 複雑な内容があれば、説明を要請するよりは、コードを明確に変更したりコメントを作成したりする。
相互尊重
常にコードの作成者を尊重し、サポートする必要がある。作成者ではなく、コードに関するコメントを提示する。
⛔️間違った例
並行（concurrency）で実行しても大きな利点はありませんが、なぜスレッドを使用しましたか？
✅ 正しい例
ここでは、並列構造による複雑性に比べ性能上の利点は見られません。性能に大きな違いはないので、そのコードはシングルスレッドで実行するのが最善のようです。
理由を説明する
上記の正しい例を見ると、聞く人が納得できる理由を提示している。全てのコメントに理由を付ける必要はないが、あなたの提案がどのようにコードの品質を改善するかを説明すれば良い。
方向を示す
最終的にCLを修正する責任は作成者にある。レビュアーが詳細な設計までする義務はない。レビュアーは、本人の適切な判断の下、問題を指摘するることもでき、より詳細に方向を提示することもできる。ただ、作者がそのコード一番よく理解しているので、レビュアーよりも良い答えを見つけることもでき、その過程を通じて成長することもできる。しかし、開発者の成長は付随的なものであり、コードレビューの重要な目標はCLを最良にすることであるため、必要があれば介入して直接的な代案やコードを提示するようにする。
作成者の説明を受け入れる
レビュアーがコードを見て理解していないので、作成者に説明を求めた場合は、コードをより明確に再作成する必要がある。また、コードレビューツールに書かれた内容は、後でコードを読む開発者にとっては役に立たない。したがって、レビューツールに説明を作成する場合は、コード管理者は知っているが、レビュアーだけは知らない内容があったりする場合に限るようにする。