コード レビューをスピードアップするための 7 つのベスト プラクティス

コード レビューは苦痛を伴う場合があります。ソフトウェア エンジニアは、レビュー プロセスが遅い、ダウンストリーム タスクが遅れている、開いているプル リクエスト (PR) と次のタスクの間を行き来するときにコンテキストの切り替えが発生する、と不満を漏らすことがよくあります。コード レビューはまた、つまらないことや自転車置き場でいっぱいになる可能性があり、関係者全員にとって貧弱な経験になります。

この問題を解決するために、一部のエンジニアは、プル リクエストとコード レビューを完全に廃止することを提案しています。スタートアップの小規模なチームではうまくいくかもしれませんが、これがすべての人、特にエンタープライズ レベルの企業にとって適切なソリューションだとは思いません。

むしろ、コード レビュー プロセスをコード作成者とコード レビュー担当者の両方にとってより良い経験にする方法はたくさんあります。これらのベスト プラクティスのうち 7 つを一緒に考えてみましょう。

＃1：プルリクエストを小さく保つ

すべてのエンジニアは、1000 行以上のコードが変更されたプル リクエストのレビューを恐れています。これらのレビューは完了するまでに数時間かかる場合があり、多くの場合、レビュアーはコードを注意深くレビューするのではなく、ざっと目を通し始めます。

解決策は、プル リクエストを小さく保つことです。小さな PR は、レビュー担当者がすべての変更がどのように連携するかについてのメンタル モデルの構築に多くの時間を費やす必要がないため、レビューがより簡単かつ迅速に行えます。また、コードの変更も少なくなり、エラーやコメントが少なくなり、作成者とレビュー担当者の間のやり取りが少なくなることを願っています。

PR を小さく保つことは、最初は難しいように思えるかもしれませんが、作業を小さなタスクに分割し、集中し続ければ可能になります。新機能の実装やバグの修正を行いながら、主要なリファクタリングを行わないでください。コードで機能フラグを使用すると、新機能の小さな部分をマスター ブランチにマージでき、本番アプリには表示されません。

PR は小さくしてください。あなたのレビュアーは感謝します。

#2: プル リクエスト テンプレートを使用する

もう 1 つの煩わしさは、コンテキストなしでプル リクエストのレビューを求められることです。 PR が何の説明もなく膝の上に置かれると、「これは何のための PR なの?」と疑問に思うことがよくあります。これはどのような問題を解決していますか?これに関連するタスクはありますか？なぜこの特定のアプローチが採用されたのですか？」

プル リクエスト テンプレートは、新しいプル リクエストごとにデフォルト テキストとして設定できる、設定可能な小さなフォームです。 PR テンプレートは、PR に関連する詳細を提供するようにコード作成者に促します。通常、PR テンプレートでは、行ったこととその理由の簡単な説明、タスク チケットへのリンク、および変更を検証するためのテスト計画が求められます。

優れた PR テンプレートには、通常、コード作成者が基本事項を見逃していないことを確認するための短いチェックリストも含まれています。このチェックリストには、単体テスト、ドキュメント、国際化、クロスブラウザー サポート、アクセシビリティなどの項目が含まれる場合があります。

以下は、すべてのリポジトリで使用したいプル リクエスト テンプレートの例です。

#3: 応答時間の SLA を実装する

プル リクエストが必要以上にレビューされていないことに気付いた場合は、チームとして、新しいプル リクエストをどれだけ迅速にレビューする必要があるかについて期待を設定する良い機会です。言い換えると、PR が取得されるまでに存在できる最大時間はどれくらいですか?一時間？ 2時間？ 24時間？

その質問に対するあなたの答えは、おそらくチームの規模によって異なります。また、チームからの内部プル リクエストと、他のチームからの外部プル リクエストに対して、異なる回答が得られる場合もあります。

応答時間の SLA (サービス レベル アグリーメント) を選択するときは、適切なバランスを見つける必要があります。新しいPRを投稿したときに、誰もが何をしていてもすぐにやめてコードをレビューすることを期待するのは合理的ではありませんが、PRが何時間もレビューされないままになることも望ましくありません.

チームメイトがフロー状態に入ることができる適切なバランスを見つけてください。彼らは自分のコードに取り組み、1 日を通して自然な停止ポイントで PR を確認できる必要があります。

個人的には、社内チームの PR には 2 時間の応答時間 SLA を、社外チームの PR には 24 時間の応答時間 SLA を設定することを好みます。

あなたとあなたのチームメイトが何を決定しようと、チームの合意があればお互いに責任を持つことができます。全員が特定の SLA に同意し、PR の 1 つについてその時間が経過している場合は、それについて人々に迷惑をかけ始めても問題ないことがわかります。

#4: ジュニアおよびミッドレベルのエンジニアをトレーニングする

トレーニングの機会はどこにでもあります。経験の浅いエンジニアのメンタリングには、彼らが使用しているテクノロジや言語について教えるだけではありません。また、効果的なコード レビューを行う方法などのソフト スキルを教えることも含まれます。

コードレビュー中に何を探すかをチームメイトに教えます。何が重要で何が重要でないかを理解するのに役立ちます。コード レビュー コメントで効果的にコミュニケーションをとる方法を教えてください。たとえば、ブロックしない提案の前に「nit」を付けるなどです。

より効果的なコード レビュー担当者になる方法については、優れたリソースがたくさんあります。 Google のCode Review Developer Guideは、すべて読む価値があります。このガイドには、コードの作成者とコードのレビュー担当者の両方にとって優れたアドバイスがあります。より生意気なリソースとして、コード レビュアーをあなたに夢中にさせる方法は、プル リクエストを作成する開発者にとって最高の (そして面白い) アドバイスです。

#5: 継続的インテグレーション パイプラインのセットアップ

ほとんどのコメントが「セミコロンがありません」や「インデントがずれているようです」などのコメントである場合、コード レビューは退屈になります。コード フォーマッターやコード リンターが処理できることについて、コード レビュー中に時間を費やさないでください。コンピューターに些細なことを自動化させて、人間が必要とする重要なことに集中できるようにします。

JavaScript プロジェクトの場合、 PrettierのようなフォーマッターやESLintのようなリンターをリポジトリ用に構成するのは簡単です。その後、 Travis CI 、 CircleCI 、 GitHub Actions 、またはGitLab CI/CDなどを使用して、リポジトリの継続的インテグレーションを設定できます。

CI パイプラインは、単体テストと共に、これらの書式設定およびリンティング タスクを実行します。プル リクエストのいずれかのステップで CI パイプラインが失敗すると、そのプル リクエストのマージがブロックされます。

これで、コード レビューのいくつかの重要な部分が自動化され、時間を節約できました。

#6: プル リクエスト レビュー アプリを使用する

場合によっては、プル リクエストのコードを確認するだけでなく、アプリの変更を手動で表示して問題がないことを確認する必要があります。セットアップ手順が複雑なアプリの場合、他のユーザーのコードを取得してローカル マシンで実行するには、5 分から 1 時間かかる場合があります。なんと頭が痛い！

プル リクエスト レビュー アプリは、新しい PR が作成されるたびにコードを短期間のテスト環境に自動的にデプロイするために使用されます。これにより、レビュアーは、コードをプルダウンしてマシン上でローカルに実行することなく、UI の変更を簡単に検査できます。これにより時間が節約されるだけでなく、レビュアーが簡単にレビューできるようになるため、レビュアーがより徹底的にレビューを行うようになります。

#7: コードの変更を視覚化するための図を生成する

GitHub または GitLab でコードを確認する場合、通常、ファイルはアルファベット順に表示されます。比較的小さな PR の場合、これは問題にならない場合があります。ただし、1 つの PR に多数のファイルが含まれている場合、それらの変更を論理的にグループ化して表示すると、全体像でそれらがどのように組み合わされているかを確認できると便利な場合があります。

CodeSee レビュー マップは、どのファイルが変更され、それらの変更が上流および下流の依存関係にどのように影響するかを視覚化するのに役立ちます。 GitHub と統合して、PR にコメントと図を自動的に投稿します。コードのインタラクティブなツアーを作成して、コード レビュー担当者をガイドすることもできます。何よりも、CodeSee マップは、オープンソース組織とそのパブリック リポジトリに無料で提供されます。

結論: コード レビューの時間を大幅に短縮する 7 つの方法

要約すると、コード レビューの時間を大幅に短縮するための 7 つのヒントを以下に示します。

1. プル リクエストは小さくしてください。
2. プル リクエスト テンプレートを使用して、レビュアーが必要とするすべてのコンテキストを提供します。
3. 応答時間の SLA を実装します。
4. コードレビュー中に探す重要事項について、ジュニアおよびミッドレベルのエンジニアをトレーニングします。
5. リンター、フォーマッター、単体テストを実行する CI パイプラインをセットアップします。
6. UI の変更を簡単に検査できるように、プル リクエスト レビュー アプリを使用します。
7. CodeSee Review Maps などのツールを使用して、コードの変更を視覚化する図を生成します。

読んでくれてありがとう、そしてハッピーコーディング！

こちらにも掲載