GitHubをコードレビューに適切に使用する方法

この記事は元々こちらで公開されました。

なぜ適切なコードレビュープロセスがそんなに大切なのか？

開発者はコードレビューに時間の30%を使っています。 これにより、PRレビューはDORA指標の主なボトルネックとなっています。しかし、このボトルネックは悪いことだけではなく、本番環境でのエラーを修正することは、開発者とそのチームの士気の両方にとって更にコストがかかります。

このブログポストでは、GitHubをコードレビューに使用するベストプラクティスについて探ります。

適切なブランチモデルを持つ

デフォルトではGitflowかGitHub Flowにすべきで、これについては以前のブログ投稿で比較しています。

ここでの大事な考え方は、GitHubをコードレビューに使用する際、チームがどう使っているかを徹底して理解することです。メインブランチとローカルで作業されるブランチの間に開発ブランチを持つかどうかに関わらず、適切なブランチモデルでは以下が必要です:

あなた自身のブランチを作成し、それらがブランチの全サイクル（作成、活性化、マージ、そしてオプションとしてブランチの削除）に従っていること。

適切なブランチ名の規約に従うこと。これはブランチがフィーチャー、バグフィックス、ホットフィックス、エンハンスメントのどれであるかを記述し、理想的にはそれに関連するプロジェクト管理チケットと命令形のフレーズ（例：「fix sidebar navigation」）に続いています。以下にあるリポジトリの例をいくつか示します。

‍

PRは自己完結したタスクであるべき

よくある失敗は、巨大なPRを作ることです。FAANG企業では非常に一般的で、彼らは「スタックされたPR」と呼ばれる独特のアプローチを使用しています。GitHubのコードレビュープロセスでこの特定の失敗を修正するための非常に興味深い方法ではありますが、本来は存在すべきではない問題への解決策です。

‍
デフォルトでは、プルリクエストは自己完結したタスクでなければならないです。プルリクをスタックする解決策を使いながら、普段通りGitHubをコードレビューに使用するのは、大きな行動の変化です。新しいgitシステムを覚え、Gitflow/GitHub Flowの代替を覚える必要があります。これを防ぐためには、チームメンバー全員が小さなプルリクを作り、小さなプロジェクト管理チケットに結び付けることを厳格に強制する必要があります。

git fetchを実行する

GitHubがコードレビューのために提供する機能は、ローカルマシンでgitが行う範囲を超えています。

git fetchを実行して、リモートブランチの最新の変更をローカルブランチに同期します。これによって、git checkout を実行するときに、すべてが正しく設定されます。

PRレビューをSlackと接続する

開発者がコードレビューに時間の30%を費やしているもう一つの理由は、彼らが作業しているタスクに集中しすぎて、同僚が作成したPRのコードレビューを忘れがちだからです。

幸いにも、彼らはGitHubでのコードレビュー体験を改善するために特別に設計されたボットを持っています。

PRごとに手動でチャンネルを作成し（その後PRがクローズされたらそのチャンネルを削除する）という実践も見られます。これは多少過剰であり、毎回徹底して続けるのは大変かもしれませんが、素晴らしい成果を生み出します。

コード品質分析を自動化する

GitHubをコードレビューに使用する際、チームの経験を向上させるためにはコード品質分析を自動化するべきです。

‍
SonarCloud、Code Climate、DeepSourceのような静的コード品質分析ツールは、これに非常に適しています。これらはPRで導入されている技術的な負債や潜在的なセキュリティ脆弱性を確認するのに役立ちます。

しかし、GitHubでのコードレビュープロセスにおいて重要な存在ではありますが、静的コード品質分析ツールを使用するだけでは、プルリクエストがビジネス要件を満たしていることを保証するには不十分です。

素晴らしいプルリクエストの説明を書く

PRが正しいブランチモデルとサイズで作成されていることは基本です。ローカルブランチをリモート変更と同期することはもう少し忘れがちですが、それでもGitHubを正しく使用するためには重要です。PRをみんなに見えるようにし、潜在的なセキュリティ脆弱性のチェックのようなより機械的な部分を自動化することは、さらに踏み込むことであり、非常に助けになります。

プルリクエストの説明を素晴らしく書かなければ、GitHubをコードレビューに使用しているリソースを十分に活用していないと言えます。素晴らしいPRテンプレートを使用すること（これはこのブログ投稿の範囲外です）もさておき、PRテンプレートの説明セクションの内容には以下が含まれるべきです:

このプルリクエストで達成しようとしているビジネス目標は何ですか？
試したアプローチは何で、なぜこれが正しい技術的アプローチなのか？ 関連するPRへのリンクがこれに役立ちます。
あなたのチームがアジャイルメソドロジーを使っている場合（今日のほとんどのチームと同様に）、このPRが対処しているタスクに関連するプロジェクト管理システムチケットへのリンク。
関連するドキュメントへのリンク
このPRや変更されるビジネスロジックについて何か関連する会話がありましたか？ SlackメッセージスレッドやZoomのトランスクリプトなど？
‍
私たちのGitHubアプリケーションは、この基準に従った素晴らしいプルリクエストの説明を書くプロセスを自動化するのに役立ちます。

こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/baristageek/how-to-properly-use-github-for-code-review-hdg