「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか：10個のヒントとは？

プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合はどうしたらよいだろうか。Red Hatのソフトウェアエンジニアが、コードレビューを行うに当たって念頭に置くべき10のヒントを解説した。

[＠IT]

デビッド・ロイド氏

　Red Hatでソフトウェアエンジニアを務めるデビッド・ロイド氏は2019年7月8日（米国時間）、コードレビューを行うに当たって念頭に置くべき10のヒントを同社の開発者向け公式ブログで解説した。プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合に役立つ指針だ。コントリビューター側としても参考になる。

　これらのヒントは、客観的で的を射たレビューを行い、プロジェクトとその参加者を前進させるという観点からまとめられている。

（1）反対意見を質問に言い換える

• 悪い例：「この変更を実行すると、『XXX』が不可能になります」
• 良い例：「どうすれば、あなたの変更を受け入れるとともに『XXX』を行えるでしょうか」

（2）大げさな表現を使わない

　望ましい結果になるように、簡潔に懸念事項を述べたり、質問したりする。

• 悪い例：「この変更は、パフォーマンスをメチャクチャにしてしまう」
• 良い例：「『X』を行うと、既存の『Y』が遅くなる可能性がありそうです。そうならないことを示すデータを測定しましたか／集めましたか」
• より良い例（もし時間があるなら）：「当面、『X』が『Y』を遅くしないことを確認するデータを集めましょう」
• 別の良い例：「この変更を行うと、シングルループ『O（n）』が二重にネストされたループ『O（n2）』になります。これはパフォーマンスに影響しないでしょうか」

（3）悪意を表に出さない

　心に留めておいた方がよい意見もある。礼儀正しくできないのであれば、関与しない方がよい。

• 悪い例：「この変更は悪手であり、全てを台無しにすると思う」
• 悪い例：「こんなコードを書いても、ソフトウェアエンジニアがあなた自身に合ったキャリアパスだと確信できますか」

（4）建設的に関わる

　問題解決の方法について、提出されたコードとは異なるアイデアがあったとしても、建設的に関われば、その2つの選択肢より、さらに良い解決策が見つかるかもしれない。

• 悪い例：「この変更はお粗末ですね。私のやり方の方がよいでしょう」
• 良い例：「『XXX』の場所で似たような変更を施したことがあります。アイデアを比べたり、組み合わせたりできるかもしれません」
• 良い例：「ちょうど似たような変更を進めていますが、『ZZZ』という理由で『X』をすることを選びました。あなたはなぜ『Y』を選びましたか」

（5）誰もが自分と同じ経験や前提知識があるとは限らないことを念頭に置く