業務において、GitHubでソースコードのレビューをする機会が増えたため
備忘として記載します。
1. プルリクエストのレビューについて
GitHubでは、ソースコードの変更点をプルリクエストとして提出し、他のメンバーにレビューしてもらうことができます。
プルリクエストのレビューは、コードの品質を保つために非常に大切です。
- ファイルごとにレビュー
プルリクエストでは、変更された各ファイルを個別に確認できます。 - 特定の行にコメント
コードの特定の行にコメントを追加することで、具体的なフィードバックをすることができます。
2. レビュー方法について
レビューのステップ
① リポジトリ名の下にある「Pull requests」をクリックします。
② プルリクエストのリストからレビューしたいプルリクエストをクリックします。
③ プルリクエスト内の「Files changed」をクリックします。
④ コメントを追加するコード行にカーソルを合わせ、青いアイコンをクリックします。
⑤ 必要に応じてコメントを入力し、「Start a review」をクリックします。
※ この段階ではコメントは保留中で、自分にしか見えません。
すべてのレビューが完了したら、後述「レビューの完了」の手順を行いましょう。
参考：レビューのチェックポイント
私がレビュー時に確認するようにしているポイントは以下の通りです。
他にも確認すべき内容があると思いますが、未だ勉強中のため割愛させていただきます。
ご参考までに。。
1.コードスタイル：コードが一貫したスタイルで書かれているか。
- インデント：
インデントが統一されているか（スペースかタブかの一貫性）。 - 命名規則：
変数名や関数名が一貫した命名規則に従っているか。
例：camelCase、snake_caseなど。 - コメント：
必要な場所にコメントが適切に追加されているか。
2.一貫性：既存のコードとの一貫性が保たれているか。
- 既存のコードとの整合性：
新しいコードが既存のコードベースと一貫しているか。
例：同じ機能を実装する際に同じパターンを使っているか。 - ライブラリの使用：
既存のライブラリや関数が再利用されているか、新しいライブラリが適切に導入されているか。 - アーキテクチャ：
プロジェクトの設計に沿った構造になっているか。
3.パフォーマンス：コードが効率的に実行されるか。
- 効率性：
コードが効率的に実行されるか（無駄な計算やループがないか）。 - データ構造：
適切なデータ構造が選ばれているか（例：リスト、セット、辞書）。
4.セキュリティ：セキュリティ上のリスクがないか。
- 入力のバリデーション：
ユーザーからの入力が適切にバリデートされているか。 - エラー処理：
例外やエラーが適切に処理されているか。
レビューの完了
① レビューが完了したら「Finish your review」をクリックします。
② 必要に応じてコメントを入力し、「Comment」、「Approve」、「Request changes」のいずれかを選択して「Submit review」をクリックします。
これで、保留中コメントすべてをレビュイーに提出することができます。
- Comment：変更の提案やフィードバックを提供する。
承認/非承認もしない場合は、Commentを選択しましょう。 - Approve：変更を承認する。
この変更で問題ないと思ったら、Approveを選択しましょう。 - Request changes：修正が必要であることを示す。
修正が必要であると思ったら、Request changeを選択しましょう。
3.まとめ
レビュアーになる機会が増え、コードは書くよりも読む方が大変なことに気付きました。
特になるべく早くマージしたいからという理由で適当にレビューをしてしまうと、後から修正することになり結果的に手間が増えてしまいます。
私も初めはレビューに時間をかけることが面倒だと感じていましたが、後からバグを修正するよりも、最初からしっかりレビューする方がはるかに効率的だと学びました。
しっかりとしたレビューを行うことで、コードの品質を保ち、後々の手戻りを減らすことができます。この記事が、誰かのコードレビューの助けになれば嬉しいです。