はじめに
皆さんは普段どのようにコードレビューを行っていますか？
中々正解があるものではないので、いまいち作業にピンと来ていない方もいるかもしれません。
そんな方々におすすめしたいのが、Code Review Developer Guideです。
Googleが、同社内のすべてのソフトウェア開発プロジェクトで実践しているプラクティスを開設する「Google Engineering Practices Documentation」の中で公開されているコードレビューガイドになります。
日本語ドキュメントもありますが、少々読みづらい部分もあるので僕なりの解釈で皆さんに内容をご紹介します。
コードレビューの目的
コード全体の質が向上していることを確認すること
コードレビューで開発を止めてはいけない
完璧なコードではなく、より良いコードで継続的に開発を行うことを意識します。
- 大事になのは「完璧」ではなく「より良い」コード
- 「より良いコード」によって継続的な改善をすることが重要
- レビュアーはPullRequestが完璧でなくても、コード全体の健全性を確実に向上させる状態になれば、承認しよう。
コードレビューのチェックポイント
コードレビューでは以下の項目についてコードの質が担保されることが期待されます。
- 【設計】そのコードは設計が良く、システムに適しているか？
- 【機能】コードは作者が意図した通りに動作しているか？そのコードの動作はユーザーにとって良いものか？
- 【複雑さ】コードはもっとシンプルにできないか？他の開発者が将来このコードに出会ったとき、簡単に理解して使用することができるか？
- 【テスト】そのコードには正しく設計された自動テストがあるか？
- 【命名】開発者は、変数、クラス、メソッドなどに明確な名前を選んだか？
- 【コメント】コメントは明確で有用であるか？
- 【スタイル】コードは当社のスタイルガイドに沿っているか？
- 【ドキュメント】開発者は関連するドキュメントも更新したか？
重要度の高いところから順に見る
変更の一番重要な点を理解し、効率的なレビューをするためには全体像から変更を確認します。
- プルリクエストのタイトル・説明を見る
- 変更コードで一番重要なファイルを確認する
- それ以外の残りの部分を確認する
依頼が来たらすぐレビューする
コードレビューはなるべく早く行いましょう。
コードレビューが遅くなると以下のデメリットがあるからです。
コードレビューが遅くなった時のデメリット
- チーム全体の速度が低下する
- 開発者がコードレビューのプロセスに抵抗し始める
- コードの健全性に影響を与える可能性がある
レビュイーに配慮し、理解しやすいコメントをする
レビュアーとレビュイーの関係性を良好に保つため、コードの可読性を上げるためのコメントの書き方です。
- やさしさを持つこと
- 根拠を説明すること
- 明確な指示を出すことと、問題点を指摘して開発者に判断を委ねることのバランスをとる
- コードの複雑さを説明するのではなく、コードを単純化したり、コードコメントを追加するように開発者に働きかける
コードの変更は小さくすること(レビュイー)
変更を小さくすることで、正確なレビューを迅速に行い、その後の変更にも強くなります。
変更を小さくすることによるメリット
- より早くレビューを行える
- より細部までレビューできる
- バグが発生しにくい
- リジェクトされても無駄な作業が少ない
- マージしやすい
- レビューの妨げにならない
- ロールバックが簡単
参考
https://google.github.io/eng-practices/review/reviewer/
https://github.com/google/eng-practices
エンジニアの副業やフリーランス、スキルアップについての情報発信してるのでフォローしていただけると励みになります！
@twinsdevelopper