はじめに
皆さん普段、コードレビューを、どのように行っていますか？
意外と、コードレビューの方法って、特に教えてもらってないとか、なんとなくやっているとか、それぞれ自分のスタイルで行っていたりしないでしょうか？
私も、自分スタイルで行っていたのですが、コードレビューにも何か基準やガイドラインがあれば効率的では、と考えて探していたら、Googleが公開しているコードレビュー開発者ガイドがヒットしました。
本記事では、このコードレビュー開発者ガイドの内容を要約して、紹介していきたいと思います。
コードレビューとは？
コードレビューとは、コード作成者以外の人が、コードを調べるプロセスのことです。
コードレビューの目的
コードの全体的な品質を、時間をかけて改善することです。
コードレビューの基準
まず、コードレビューの目的の達成の為に、開発者と、レビュワーは以下のように、プロジェクトを進行させる必要があります。
開発者
自分のタスクを進めて、レビュワーにコードを提出し、プロジェクトを前進させないといけません。
そのため、レビュワー側もいちいちコードに難色を示し、コードの変更を取り入れないと、プロジェクトが前進しません。
レビュワー
提出されたコードの品質を確認するのは、レビュワーの義務です。
難色を示して、コードの変更をなかなか取り入れないのもよくないが、時間的な制約などで、確認レベルを下げて、変更を取り入れてしまうと、品質を悪化させてしまいます。
では、どうすればよいか？
ガイドラインでは、以下のような基準を設定しており、全ガイドラインの最上位の原則としています。
一般に、CL が完璧でなくても、その変更がシステムのコードの全体的な健康状態を改善すると確実にわかれば、レビュアーは CL を積極的に承認すべきである。
ポイントは、「完璧」なコードは存在せず、存在するのは、「より良い」コードだけということです。
追求すべきは、継続的なコードの改善の為、コードが完璧ではなくでも、承認して、プロジェクトを進めるべきです。
但し、さらに改善できそうな点を見つけたら、気軽にコメントを残すべきです。
もし重要ではなく、無視しても構わない指摘の場合、コメントなどをつけて開発者に知らせるとよいです。
※ガイドラインでは、「Nit:」（あら探しや細かい指摘という意味）のようなプレフィックスを付ける例が記載されています。
コードレビューの観点
目的と基準がわかったので、続いてどの観点で、コードレビューをしていくかです。
以下の観点でコードレビューをしていきます。
設計
全体の設計面を確認します。
コードレビューで最も大切なことになります。
機能性
開発者の意図通り、動作するか、また、使用するエンドユーザーにとって適切な機能かを確認します。
複雑性
コードが必要以上に複雑になっていないか、確認します。
関数や、クラス名など、1行1行複雑になっていないか、確認します。
※「複雑」＝「コードを読んですぐに理解できない」
テスト
コードの変更に適したユニットテスト、結合テスト、E2E テストを依頼します。
命名
関数、クラス名など、あらゆるものに適切な命名がされているか確認します。
コメント
コメントが記載されている場合、明確でわかりやすいか、確認します。
コードが「何」をしているかではなく、「なぜ」存在するのかをコメントすると良いです。
スタイル
スタイルガイドがある場合は、それに従っているか確認します。
ドキュメンテーション
ビルドや、リリースの方法など変更する場合は、それに関連するドキュメンテーションも更新されているか確認します。
コードレビューのスピード
続いて、レビュー依頼が来たら、いつレビューするかです。
皆さんも気になるポイントではないでしょうか？
結論から言うと、
コードレビューの依頼が来たらすぐに着手するのが良いです
素早くコードレビューを行わないと、以下デメリットがあります。
-
チーム全体の開発速度が遅くなります。
レビューをしないと、チームメンバーのタスクが滞ってしまいます。 -
開発者が、コードレビューのプロセスに不満をもってきます。
レビュアーのリアクションが遅いのに、修正依頼が多量となると、開発者はストレスを感じてしまいます。 -
コードの品質の低下に繋がります。
レビューが遅いと、時間の制約などあり、コードの品質が良くない状態でも提出してしまってよい雰囲気が広がってしまいます。
レビュアー自身のタスクがある時
レビュアー自身もタスクがあり忙しい時があると思います。
コードを書くような集中的に取り組むべきタスクの最中は、中断してまでコードレビューしてはいけません。結果的に、余計なコストが掛かってしまう可能性があります。
とはいえ、最長一営業日以内に返答してください。
素早い応答
どうしてもレビュアーの時間がとれないときは、広い観点で見た初期段階のコメントを残したり、他のレビュアーを紹介するも良いです。
レビューが完了していなくても、素早い応答があれば、開発者に余計なストレスを与えないです。
レビューコメントの書き方
最後にレビューコメントの書き方になります。
以下の観点で、コメントを書くとよさそうです。
要約する
コメントは丁寧に、理由を説明してください。
礼儀正しさ
礼儀正しく、開発者に敬意を払った書き方がよいです。
必ずコードについてコメントし、開発者本人についてコメントしないように心がけます。
理由を説明
レビューコメントに必ず理由を加えてください。
指示を与える
コードを修正する責任は、開発者なので、基本的には、コード修正は、開発者に任せるのが良いですが、
一方で直接的な指示や、コードを提案することが有益になる場合があります。
説明を受け入れる
コードを理解できない場合は、説明をしてもらったり、コードを書き直してもらうように、依頼しましょう。
まとめ
いかがでしたでしょうか？
ガイドラインには、開発者はもちろん、レビュアー自身にも配慮された、最適な方法が示されていると思いました。
ガイドラインを基準に、コードレビューしていくと、レビューの方法にも迷わないですし、コードの品質も向上していくと思います。
本記事では、要約して簡単に紹介してますが、
実際のガイドラインはもっと充実した内容となっていますので、興味がある方は、是非ご一読ください。
最後まで読んで頂き、ありがとうございました。