この文書はCode Health: Too Many Comments on Your Code Reviews?の翻訳です。
コードレビューは個々のコードチェンジをスローダウンさせるかもしれない。しかし、他の経験豊富なエンジニアの知識から学び、君のコードを改善する機会でもある。どうすればそれを最大限に活用できるだろうか？
君のコードチェンジが最初のラウンドのレビューで承認されることを目指そう。もし君のコードレビューが何ラウンドにも渡ってコメントをもらい続けるようなら、このティップスによって時間が節約できるかもしれない。
レビューアの時間を賢く使おう ー それは限られたリソースだ。 もし彼らが、君でも簡単に見つけられるような問題を指摘しているなら、君はチーム全体の生産性を下げている。
コードレビューに送る前に:
コードを再評価しよう: テストがパスしたからといってすぐにレビューに送るのは止めよう。一歩下がって全体を再考しよう ー デザインはクリーンか？特にもう遅い時間なら、翌朝にもっといいアプローチを思いつかないかを待つのもいい。こうすることは個々のコードチェンジを遅らせるが、長期的な平均スループットをより大きくする。
気軽にデザインに関して議論しよう: もしよく分からないことがあるなら、ペアプログラミングをしたり、直接話したり、早い段階で変更を送り、全体のデザインに関して「プレビュー」を頼もう。
コードチェンジをセルフレビューしよう: コードについて何も知らない人になったつもりで、できる限り批判的にコードをみてみよう。コードレビューツールを通してみると普段のIDEとは全く違った視点でみることができる。こうすることでレビューの回数を減らすことができる。
変更を分かりやすいものにする: 複数の変更を一度にするとコードレビューは難しくなる。セルフレビューの際に、変更をより小さなサイズのものにできないか考えよう。例えば大規模なリファクタリングやフォーマットの変更は別のコードレビューに分割しよう。
サブミットメッセージに大事な情報を隠さないように: 大事な情報はコードにも書こう。後でコードを読む誰かがサブミットメッセージを見ることはほぼない。
コードレビューのコメントに対応するとき:
自明ではないコメントに対応したあとではコードを再評価しよう: 一歩下がって、真っ新な目でコードを確認しよう。一通りの変更をし終えた後は、その変更が可能にする、あるいは示唆する、さらなる改良が見つかるものだ。リファクタリングと同様に最善のデザインに到達するには何ステップもかかるだろう。
レビューアがどうして各コメントをしたのか理解しよう: コメントの裏にある理由を理解していないなら、ただ変更するのではなく、レビューアに尋ねて、新たなことを学ぼう。
レビューアの質問にコードで答えよう: 単に返答するのではなく、コードをより分かりやすくしよう。（例えば、変数名を改善したり、真偽値を列挙型に変更したり）コメントを加えるのもいい。後になって、他の誰かが同じ質問をするだろうから。