イントロダクション#
Code Review はソフトウェア開発プロセスで非常に重要なタスクです。これにより、コードの問題を発見し、コードの品質を向上させ、チームに知識を共有する機会を提供することができます。この記事では、Code Review に関する経験とテクニックについて詳しく説明し、参考になる情報を提供します。
Code Review の目標#
Code Review を行う前に、このプロセスの主な目標を明確にする必要があります：
1. コードスタイルの統一#
コードスタイルの統一は、コードの可読性と保守性の向上に重要な意味を持ちます。Code Review を通じて、チームメンバーが同じコーディング規約に従うことを確認し、コードをより整理された状態にすることができます。
2. チームのスキル向上とコミュニケーションの促進#
Code Review は、チームメンバー間の知識共有を促進するだけでなく、レビュアーがコードとビジネスロジックをより深く理解することもできます。レビューのプロセスでは、他のチームメンバーに質問したり、技術を共有したりすることができ、チーム全体の技術レベルを向上させることができます。
3. コードの品質向上と潜在的なリスクの削減#
Code Review を通じて、コードの潜在的な問題を発見し、コードの品質をさらに向上させることができます。以下は、Code Review のプロセスで発見される可能性のある問題の種類のいくつかです：
- 境界条件：コードが空の値、特殊文字などのさまざまな境界入力を正しく処理できることを確認します。
- 過剰なカプセル化またはカプセル化の不足：適切なカプセル化は、コードの可読性と保守性を向上させることができます。Code Review のプロセスで、過剰なカプセル化やカプセル化すべきであるにもかかわらずカプセル化されていない場合に注意を払う必要があります。
- 見落とされる可能性のある共通コンポーネント：プロジェクトでは、既存の共通コンポーネントを見落とすことがあります。また、ビジネスと他のメンバーのビジネスの間に潜在的な共有コンポーネントが存在する可能性もあります。Code Review は、再度チェックするための手助けとなり、コードの重複を減らすことができます。
実際の操作#
Code Review の目標を明確にした後、次に、実際の操作のプロセスとテクニックについて詳しく説明します。
Git の操作#
Code Review を行う際には、特定の Git ブランチ操作のプロセスに従う必要があります：
masterブランチから要件ブランチ（例：release/v1.0）を切り出します：
git checkout -b release/v1.0
- 開発者は要件ブランチ（例：
release/v1.0）から機能ブランチ（例：feat/v1.0-sub-module）を切り出します：
git checkout -b feat/v1.0-sub-module
- 機能ブランチの開発が完了したら、要件ブランチに対してマージリクエスト（MR）を作成します。MR を作成する際には、以下の情報を提供する必要があります（MR テンプレートを使用して統一的に管理することができます）：
- この MR はどの問題を解決していますか：なぜこの MR が必要なのか、要件の説明やドキュメントなどを添付することができます。
- この MR で何が変更されましたか：どのモジュールのコードが追加、変更、削除されたかを簡単に説明します。
- 他の機能モジュールに影響を与える可能性がありますか。
注意事項：
- 1 つのブランチに対して 1 つの MR を作成します。
- 1 つのブランチで複数の MR を作成しないでください。
- MR をマージする際には、「Squash commits」と「Delete branch」オプションを選択し、「Fast-forward merge」を使用します。競合を処理するために
rebaseを使用します。
- MR がマージされた後、ローカルで複数のブランチを一括削除します：
git fetch --prune && git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D
::: warning
このコマンドは、ローカルブランチとリモートブランチの差分を比較し、対応するリモートブランチが存在しないローカルブランチを削除します。
この操作は危険なため、複数の削除対象ブランチがある場合にのみ使用することをお勧めします。
:::
レビュアーへの通知#
MR を作成した後、レビュアーにすぐに通知してください。レビュアーは、対応するレコードをタスクとして設定し、追跡できるようにすることができます。
レビュアーの作業#
通知を受け取ったら、レビュアーは 1 営業日以内にレビューを完了する必要があります。理想的な場合は、すぐに処理する必要がありますが、他の緊急のタスクがある場合を除きます。効率的なレビュープロセスを確保するために、以下のポイントに注意する必要があります：
-
コミッターは、レビュアーが 20 分以内にレビューを完了できるように、MR のサイズを制御する必要があります。具体的な要件は以下の通りです：
- 1 つの MR の作業量は 2 営業日以内に制御することが望ましいです。
- 8 つを超えないファイル
- 500 行を超えないコード
- 特殊な場合に大きな MR が発生した場合は、事前にレビュアーと予約を行うこと
- MR のトピックを単一にすること
- レビュアーとの面談で要件の背景やインタラクションを説明することで、スピードを上げることができます。
-
レビューのプロセスでは、以下のチェックリストを参照してください：
- 命名規則
- ディレクトリの規則
- コードの規則
- スペルチェック
- ロジックの再利用チェック
- 再利用可能なコンポーネントのチェック
- TypeScript の型チェック（
anyまたはasを使用する場合は注釈を付ける必要があります） - コメントのチェック（コードが理解できない場合は最適化が必要かもしれませんが、ビジネスロジックが複雑な場合もありますので、適切なコメントを追加する必要があります）
- 他のチームのコーディング規則
-
人的コストを削減するために、ESLint、Prettier、Stylelint などの自動化ツールを使用することをお勧めします。
推奨されるツール#
Code Review の効率を向上させるために、VSCode を使用している場合は、次のツールを使用することをお勧めします：
- VSCode GitLab Workflow プラグイン：このプラグインを使用すると、MR のコードを簡単にローカルに取得し、VSCode 内で直接コメントを行うことができます。
- VSCode Code Spell Checker プラグイン：このプラグインを使用すると、単語のスペルチェックを行い、潜在的なスペルエラーを見つけることができます。
追加の注意事項#
Code Review を行う際には、次のポイントに注意する必要があります。これにより、プロセス全体の効果と効率が向上します：
- 複雑な要件には事前に設計を行い、レビュアーとの最初のコミュニケーションを行う必要があります：これにより、数日後に問題が発生した場合の改造の時間コストを抑えることができます。
- 複雑または重要なロジックにはテストを追加してください：まずは簡単な JavaScript と TypeScript のメソッドのテストから始めることができます。
- 1 つの MR につき 3 回以上のやり取りがある場合は、第三者の介入を要求してください：意見が表明され、相互理解がされているにもかかわらず、合意に達しない場合は、すぐに第三者の助けを求めてください。大きな議論がある場合は、チームの会議で規格を決定した後、コーディング規則に記録してください。
- スケジュールの評価時には、Code Review に十分な時間を確保してください：特に最初のレビューでは、多くの問題が発生する可能性があり、時間がかかる場合があります。
- デバッグとテストの期間中、通常は MR が大きく、コードのレビューが比較的容易です：Code Review がバグ修正の進行を妨げる心配はありません。
- MR で解決できない問題に遭遇した場合：後続の MR のマージが遅れないように、まず問題を issue に記録し、MR に関連付けて、後で issue を個別に処理します。
- レビューは文句を言うためのものではなく、できるだけ優しい言葉を使ってください：
- "私は〜だと思います"、"〜のようにすることができます" などの言葉を使用してください。
- "あなたは〜"、"エラー" などの言葉を使用しないでください。
- 良いコードを見つけた場合は、褒めることを惜しまないでください。
- コメントには、提案のコード例を残すようにしてください。コードは言葉よりも直感的です。
- 自分自身の MR を事前にレビューしてください：他の人にレビューを依頼する前に、自分自身でコードを注意深くチェックしてください。
- コードは機械ではなく人間のためのものです：理解しやすく、保守しやすいコードを書くようにし、他のチームメンバーが Code Review や後続のメンテナンスをより良く行えるようにしてください。