コードレビュー中の取り下げに対応する

開発者がコードレビュー中に取り下げることがあります。開発者があなたの提案に同意できないこともありますし、あなたのレビューが厳格すぎるために開発者が不満を抱いてそうすることもあります。

正しいのは誰か？

開発者があなたの提案に同意できないとき、最初に少し考慮していただきたいのは、開発者のほうが正しいのではないかということです。 よくあることですが、開発者はあなたよりもコードを間近で見ているため、ある側面では開発者のほうが優れた洞察を持っていることもあります。 開発者の議論は筋が通っているでしょうか？コードの健康状態という視点から理にかなっているでしょうか？ そうであれば、開発者が正しいということを認め、問題を水に流しましょう。

しかしながら、いつでも開発者が正しいとは限りません。その場合、レビュアーはどうして自分の提案が正しいと思うのかを踏み込んで説明しましょう。 まず開発者の応答に理解を示し、それから変更が必要な理由を付け加えるのが良い説明です。

特に、レビュアーがコードの健康状態を良くする提案をしていると思われる場合には、その変更によってさらに作業が発生するもののそれに見合うだけコードの品質が改善すると見込まれれば、粘り強く変更を勧めるべきです。 コードの健康状態の改善は、スモールステップで行われます。

提案がきちんと理解してもらえるまで何ラウンドか説明しなければならないときもありますが、いつも丁重に説明するのを忘れず、開発者の言葉にきちんと耳を傾けた上でただ同意できないだけなのだということを知らせてください。

人を悩ませる開発者

レビュアーが改善を要求すると開発者が傷つくのではないかとレビュアーが思い込んでいる場合があります。確かに開発者が傷つくこともありますが、普通はそれは一時的なことで、時が経つとコードの品質改善に協力してくれたことに深く感謝するようになるものです。 丁重なコメントを心がけていれば、実際、開発者は傷ついたりしません。そういった心配はレビュアーの杞憂です。 傷つくことがあるとすれば、コードの品質改善の要求よりもコメントの書き方のほうに原因があるものです。

あとで片付ける

CL 取り下げのよくある理由は、（もっともなことですが）開発者が仕事を完了させたいからです。この CL を取り入れてもらうために何度もレビューのラウンドを重ねたくないのです。そのため、開発者はこう言います。あとで別の CL でその問題を片付けるから、この CL については今は LGTM してほしい、と。 きちんと有言実行し、問題を解決するフォローアップの CL をすぐに書いてくれる開発者もいます。けれども、経験則が示すところによると、開発者が最初の CL を書いてから時間が経てば経つほど、その問題を片付ける可能性は低くなります。 事実、開発者が現在の CL の直後に問題を片付けるのでなければ、その機会は完全に消失します。こうなるのは開発者が無責任だからではなく、開発者がたくさんの仕事を抱えていて、他の仕事が押し流されて問題を片付けるのを忘れてしまったり時間を取れなくなったりするからです。 ですから、最良の選択肢は普通、CL がコードベースに取り込まれて「完了 (done)」する前に、開発者に今片付けてもらうことです。「あとで片付ける」を許容するとコードベースは悪化します。

CL が複雑さを新たに持ち込む場合、緊急事態でない限り、それが取り込まれる前にきちんと問題を片付ける必要があります。CL が周辺の問題を顕在化しているのに開発者がすぐにその問題に取り組めないときには、問題解決のためにバグを整理保存し、忘れないように自身をアサインしておきます。コードの直すべき箇所に任意で TODO コメントを入れることもできます。

厳格さに関するよくある不満

以前はゆるいコードレビューをしていた人が急に厳格なレビューをするようになると、開発者があからさまに不満を言うようになることがあります。コードレビューのスピードを改善すると、そうした不満は解消されることが多いです。

ときには数カ月間にわたってこうした不満がくすぶり続けることもありますが、厳格なレビュープロセスによってコードの品質が向上しているのが目に見えてわかるようになるにつれて、厳格なコードレビューの価値を見直すようになります。それどころか、厳格なレビューによって付加された価値にちょっとしたきっかけで気づくようになると、最もあからさまに反対していた開発者が、最も熱心な支持者になることさえあります。

意見の対立の解消

上記の原則に従ってレビューした結果、それでもレビュアーと開発者の間で解決できない意見の対立が生じた場合、対立を解消するためのガイドラインおよび原則としてコードレビューの基準を参考にしてください。