役立つコードレビュー（CR）のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。

コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。

前提

まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。

• 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。
• コードではないシナリオでフィードバックを出すことが求められている。あるいは、チーム内でフィードバックを出そうとしている。
• チームは、少しでも良いコードを作り出したいと思っており、パーフェクトという言葉は、形容詞ではなく動詞であることを理解している。明日、もっと良い方法が見つかるかもしれない、というオープンな心構えを保っている。
• 勤務先は高品質のコードに価値を置き、何事もどんどん「リリース」できるわけではないのを理解している。リリースがカギカッコ付きなのは、テストやレビューが疎かになったコードが機能しないことはよくあるからだ。

これである程度の基本ルールが整ったので、早速始めましょう。

1. 私たちは人間

レビューしようとしているのは、誰かが時間をかけて書いたコードなのだということを理解しましょう。彼らはそれを素晴らしいものにしたいと願っているのです。同僚は最善の意図をもって行動していますし、下手なコードを公開したいと思う人はいません。

客観性を保つのがかなり難しいこともあるかもしれません。常にコードそのものを批評するよう心がけ、それが書かれたコンテキストを理解するよう努めましょう。できる限り、やんわりとした言葉で伝えましょう。たとえば、

あなたのメソッドの書き方は分かりにくいですよ。

といった言い方ではなく、コードそのものについて述べるように言い換えましょう。

このメソッドは私には少々分かりにくいです。この変数にもっと良い名前をつけられないでしょうか。

この例では、読み手としての自分たちがコードについてどう思うかを説明しています。彼らの行動や意図を問題にしているのではありません。自分たちと、自分たちのコードに対する理解について述べているのです。

あらゆるプルリクエストはそれぞれに 「難しい話し合い」 を伴うものです。チームメイトと理解を共有できるように努力し、さらに良いコードを目指して一緒に努力しましょう。

もし、知り合って間もないチームメイトがいて、あるプルリクエストに対して重要なフィードバックがあるなら、その人と一緒にコードを1行1行見ていきましょう。同僚と関係性を築き始める良いチャンスになるはずです。ぎこちない感じがなくなるまで、同僚1人1人とそれを繰り返しましょう。

2. 自動化する

コンピュータが規則を決断、強制できるのなら、コンピュータにそれを任せましょう。タブかスペースかを議論するのは、人間の時間の生産的な使い方とは言えません。代わりに、規則はどうあるべきか合意を得るのに時間を投資しましょう。これはチームが「異議を唱え、コミットせよ」の原則を、低リスクのシナリオでどれだけ活かせるかが分かる機会でもあります。

言語とモダンなツーリングパイプラインは、規則を強制し（リンティング）、それを繰り返し適用する手段を備えています。Rubyには、 Rubocop があります。JavaScriptなら eslint です。使用言語のリンタを見つけて、ビルドパイプラインにつなぎましょう。

既存リンタがないようなら、自分で書いてしまいましょう！　独自の規則は非常にシンプルに書けます。Gustoでは、非推奨のクラスが使われているのを発見したり、仲間たちに Sidekiq のベストプラクティスに忠実に従うようそっと促したりするのにカスタムのリンタ規則を使っています。

3.レビューは全員で

コードレビューの責任を優秀なAさんに丸投げしたいという誘惑にかられることもあるでしょう。

Aさんはコードの達人で、いつも何がベストなのか分かっています。システムを隅から隅まで知り尽くしていて、チーム全員の在籍期間を合わせたよりも長く会社にいます。

でも、Aさんがあることを理解できるからといって、チームの他の人たちにも理解できるとは限りません。また、Aさんのコードレビューについて何か指摘するのをチームの若いメンバーがためらうかもしれません。

チームの多様なメンバーの間にレビューを分散させるとチーム力学が健全化され、コードも改良されることに私は気付きました。初級エンジニアがコードレビューで口にする最強のフレーズの1つは「このコードは、ややこしい」です。これが出てきたら、コードを明瞭化、単純化するチャンスです。

レビューは広く分散させましょう。

4.読みやすさを心がける

Gusto ではコードプロジェクトの管理にGitHubを使っています。GitHubのほぼ全ての <textarea> では マークダウン をサポートしているので、コメントを簡単にHTML形式に変換することができます。

マークダウンを採り入れると、コードを読みやすくするために役立ちます。GitHubにはシンタックスハイライト機能があり（あなたの選んだツールにもあるでしょう）、コードスニペットをはめ込むのに便利です。インラインコードに単一のバッククォート（ ` ）を使ったり、コードブロックに三連バッククォート（ ``` ）を使ったりすると、上手に考えを伝えることができます。

特に、コメント内にコードを書くなら、マークダウンの構文に慣れましょう。そうすれば、レビューが具体的で的確なものになります。

5.少なくとも1つは肯定意見を伝える

コードレビューは本質的に否定的なものです。 「世の中に出す前に、コードの間違いを指摘してください」 ということですが、非常にデリケートな問題です。書き手は、時間をかけて作った大事なコードを改善するにはどうすればいいか指摘して欲しいと思っています。

ですから、最低でも1つは肯定的な意見を伝えるようにしましょう。有意義で個人的な意見にすることが大切です。皆がこれまで苦労していた問題の取り扱い方を誰かが掴んだようなときには、それをはっきり伝えましょう。ただイイネをするだけでも、「良いね」といった簡単なコメントでも構いません。

コードレビューで毎回、少しでも肯定的な評価を伝えれば、チームの雰囲気がさりげなく協力的になります。コードが改良されれば、結局は全員のためになるのです。

6.代案を示す

私は、特に言語やフレームワークを学び始めたばかりの人には、実装の代案を示すように心がけています。

ただし、これには注意が必要です。やりかたを間違えると横柄で身勝手に見えるので、「私ならこうするかも」と控えめに提案します。自分の代案を客観的に見て、利点と欠点について話し合いましょう。上手にやれば、皆の手持ちの技術知識を拡張するために役立ちます。

7.遅延は重大

コードレビューは短期で完了することが重要です（次の規則 「小さくまとめる」 を使えば、さらに簡単に短縮できます）。

コードレビューの遅れが長引けば、生産性とモラルが犠牲になります。3日も前にレビューに出したプルリクエストの話を聞かされたりすると不快になります。 「なんてことだ。時間の無駄だったじゃないか」 とか。レビューは放っておけば堂々巡りするようにできています。これを改善するには、進捗状況は個人ではなくてチーム全体の物差しだと、チーム全体にクギを刺しておく必要があります。チーム全体がコードレビューの遅れに気を遣い、チームとして成長するようにしましょう。

レビューの遅れを短縮したいのなら、 「コードをレビューしてから、新しいコードを書く」 という規則を座右の銘にしましょう。

遅れに正面から取り組むための戦術として、コードレビューでペアリングを試してみましょう。ペアリングステーションを利用するか画面共有を始動して、レビューのウォークスルーと考察を行います。ペアでソリューションに取り組み、コードを承認状態にもっていきます。

8.プルリクエストは小さくまとめる

コードレビューについて受け取るフィードバックの質は、プルリクエストのサイズに反比例します。

核心を突いた建設的なフィードバックを最優先に考え、プルリクエストは小さいほど読み手にとって扱いやすいということを覚えておいてください。

プルリクエストを小さくするなら（そして、 The Teeth を避けるなら（訳注：プログラム製品の開発の際は大幅な変更を加えたリリースを避けて小さな段階を重ねるべきという考え方））、もっと大きな視点から話し合いを行うために別の土俵が必要になります。このプルリクエストを今週の（または今月の）作業量にどうやって合わせるか？　目標はどんなもので、このプルリクエストを使えばその目標に到達できるのか？　ホワイトボードやアドホック会話は、このようなタイプの議論に最適です。プルリクエストが小さくなると、そのプルリクエストが書かれたときの状況を心に留めておくのが難しくなるかもしれません。
「小さい」とはどれぐらいなのかは、言語やチームによって異なります。私は、プルリクエストを全体で300行未満にするように心がけています。

まとめ

あなたとチームがコードレビューを改善するために、この8つのヒントが役立つよう願っています。コードレビューのプロセスを改善すれば、コードは改良され、チームメイトはハッピーになります。ビジネスも発展すると良いですね。

チームのコードレビューを改善するために、あなたはどんな戦術を使っていますか？ ツイッターで お知らせください。