コードレビューとは、ソースコードの作成者とは別の人物がコードを詳しく調べて問題がないか検討することであり、プログラムの品質を守るのに、欠かせない工程の一つです。
しかし、コードレビューは簡単ではありません。「適切な書き方が分からない」といった悩みを抱えている人も多いでしょう。
本記事では、コードレビューを有用なものにするための適切な実施方法について解説します。
コードレビューとは?
コードレビューとは、プログラムのソースコードを作成者以外の人物が検証して、その所感を作成者に文書や口頭でフィードバックすることであり、ソフトウェア開発における重要な工程です。
人間が書いたプログラムコードには、単純な誤記から根本的な間違い(思い込み)、設計段階で策定された仕様や要求が満たされていない、効率や性能が悪くなっている、冗長になっている、脆弱性、客観的なプログラムのわかりにくさ、規約を守っているかなど、さまざまな誤りや問題点をはらんでいる可能性があります。
こういった問題はコードを書いた本人による検証では見落としてしまったり、そもそも認識自体できないといった場合があるため、別の開発者がコードに対してあらゆる観点から調査・検討をしてもらうことを「コードレビュー」といいます。
コードレビューを実施することでコード作成者個人の力量に依存することなく、一定のコードの品質を保てます。見落としや思い込み、癖による不良箇所が生じたり、のちのち、ほかの人が保守しにくくなることを防止します。
また、開発チーム内でコードレビューをすることで、互いの作業範囲を理解する機会になり、チーム内での連携強化につながります。人に見られることが前提となるので、分かりやすい論理や記述を意識するようになり、可読性が上がるといった効果も期待できます。
以後、コードの作成者をレビュイー、コードの検閲者をレビュアーと呼びます。
コードレビューの目的は?
以下に、ここまで説明してきたコードレビューの目的をまとめます。
- 人為的ミスによるシステムの不具合の防止
- 可読性の向上
- メンバー間での認識の統一
- メンバーのスキルの向上
コードレビューのやり方は?
コードレビューを行う上で大事なポイントは以下のとおりです。
- レビューの種類を押さえる
- 根拠を示す
- 進捗に応じて見るポイントを変える
- レビュー後でも修正可能かを意識する
- コメントの仕方に配慮する
- 口頭でのやり取りも併用する
レビューの種類を押さえる
コードレビューは、レビュイーに対して指摘項目の優先度を明確に示す必要があります。
項目 | 意味 |
MUST | 対応すべきこと |
nitsまたはask | 細かい指摘(直さなくてもいいが気になること・ききたいこと) |
IMO(In my opinion) | 自身の見解・意見 |
fyi | より良い方法を一応教えておきたいこと |
根拠を示す
「~~すべき」のみでは、レビュイーは理由が分からず困惑してしまいます。そのため、レビューには必ず、その根拠を示しましょう。参考文献を添えるとより親切です。
進捗に応じて見るポイントを変える
進捗に応じてチェックするポイントが変わります。たとえば、作成途中のソースコードをプルリクエストするというやり方もありますが、この段階では、変更の必要性や設計・実装の方針に対する問題の有無といった前提部分をみます。この時点ではまだ細かいスタイルに関して指摘する必要はありません。具体的な実装方法や書き方に関しては実装が終わってからレビューします。
レビュー後でも修正可能かを意識する
コードレビューに費やせる工数や時間は無限にあるわけではありません。そのため、レビュアーは指摘箇所の実現可能性やプロジェクト全体にもたらすメリットを考慮する必要があります。たとえば、ビューの変更はマージ(ファイルやデータの統合)後でも簡単に行えますが、データベースの変更はそうはいきません。データベースのような変更がしにくい箇所を優先的にレビューするのがいいでしょう。
コメントの仕方に配慮する
コードレビューはコミュニケーション手段の一つでもあるので、コミュニケーションを円滑にするために絵文字を使うのも良いでしょう。
良いものに「良い」という
フィードバックは至らない箇所を改善するためだけにあるわけではなく、良い部分を伸ばすためでもあります。ポジティブなフィードバックをもらえたレビュイーは、モチベーションが上がりますし、チーム全体としても雰囲気が良くなるでしょう。
口頭でのやり取りも併用する
テキストコミュニケーションと口頭でのコミュニケーションではそれぞれにいいところがあるのでその特性をうまく活用しましょう。テキストコミュニケーションは文書として残るため再利用しやすい、その場にいない人にも後から伝えやすいといったメリットがあります。一方、口頭のコミュニケーションには、行間を補えることや複数人で意見を交わせるといったメリットがあります。そのため、文面だけでは伝えにくい場合は口頭でのやり取りも併用した方がいいでしょう。
コードレビューで見るべき観点は?
次に、コードレビューをする時に、どのような観点で行うべきかを、チェック項目の形で紹介します。ただ、細かい観点に関してはチームによっても変わってくるので、以下の項目を参考にして、チームの方針に合ったチェック項目を適宜作成しましょう。
仕様や設計に合致しているか
大前提として、ソフトウェア開発の仕様・設計要求を満たしている必要があります。
- 要求事項を網羅しているか
- 論理は合っているか
- エッジケース(まれに発生し得るイレギュラーなバグや脆弱性)を想定できているか
- ソフトウェアの動作に問題はないか
- 満たすべき環境で問題なく動作するか
- より良い設計はないか
などの項目が挙げられます。
自動テストを導入している場合は上記項目のほとんどを自動化できますが、コードレビューが不要になるわけではありません。ソースコードと併せてテストケースが適切に更新されているかも検証する必要があります。
チームのコーディングルールに準拠しているか
開発チームのコーディングルールに準拠しているかをチェックする必要があります。ルールに沿わない書き方になっていると、読み手に取って理解しにくく、結果的に作業効率が悪くなってしまいます。コーディングルールの周知はメンバー間の認識の統一ができ、トラブルも抑制できるのでおすすめです。
- コメントが理解しやすく書かれているか
- ファイル・クラス・関数・変数などの命名がわかりやすいか
- アルゴリズムが複雑化していないか
などの項目が挙げられます。
最適な書き方になっているか
ソースコードが最適であるかもチェックします。最適なソースコードに修正することで保守性が向上するだけでなく、潜在的なバグの抑制にもつながります。
- 冗長な処理を集約できないか
- コードが冗長になっていないか
- 不具合につながる部分がないか
- 変数のスコープは適切か
- 並列処理がデッドロック(行き詰まり状態)する恐れはないか
- 不要なソースコードはないか
- DRY(コードが重複せず)に書けているか
- よりよい書き方はないか
- 導入したツールに問題はないか
- 使用できる既存ツールはないか
などの項目が挙げられます。
有用なコードレビューを行うコツは?
レビュイーに不足している知識がどのレイヤーかを考える
レビュイーがコードを間違えたのには単純なケアレスミスから論理の誤認、知識不足まで、さまざまな理由が考えられます。コードレビューの際、レビュアーは「レビュイーに不足している知識がどのレイヤーか」を確認するといいでしょう。その返答の内容次第で、レビュイーの現状課題を可視化できます。それを踏まえてレビューを進めることでレビュイーの成長にもつながります。
チーム間でコードレビューの目的・観点を共有する
より質の高いコードレビューを行うには、第一に開発チーム内でレビューの観点を共有することです。開発の目標やそれに基づいたレビューの目的・観点が自明であればメンバー内で解釈の齟齬もなくなり、レビューする側・される側で建設的なやりとりができるでしょう。レビューの目的があれば、チェック箇所が絞れて効率的にチェックできます。
自動化できる部分は自動化する
細かいスタイルといった見た目部分は自動化してしまうのもいいでしょう。コードの見た目を整えるのはフォーマッタを、初歩的なコード規約はlinterを使うことで自動的に統一できます。ルールを追加する場合はlinterの設定を修正するなどできるので、極力自動化できる仕組みにすることをおすすめします。
コードレビューの注意点は?
コードレビューの注意点には以下のようなものがあります。
- 多くの工数・時間がかかる
- レビュアーの技量に左右される
- 雰囲気が悪化する可能性がある
多くの工数・時間がかかる
プログラムの書き方は書いた人によって個性が出やすいのでレビュアー間でも意見が分かれやすく、結果的にコードレビューに多くの工数・時間を費やすことになるケースもあります。コードレビューに時間がかかるとその後の開発スケジュールを圧迫することになるので、どこまでをレビューするのかといったゴール設定や工数削減策の制定をする必要があります。
レビュアーの技量に左右される
レビュアーの技量でコードレビューの質も変わります。複数人でレビューを行う場合でもそれなりの経験がある人が少なくとも一人は必要でしょう。
雰囲気が悪化する可能性がある
つい議論が白熱するとチーム内の雰囲気が悪化する可能性があります。「以前も指摘しましたが、~~~」といった人格攻撃は厳禁です。あくまで「レビューするのはコードであってコードの作成者ではない」ということに留意しましょう。また、良い部分は良いと伝えるといったコミュニケーションルールを決めておくといいでしょう。レビュアーが柔軟に対応することで、レビュイーも萎縮せず質問しやすくなるでしょう。
コードレビューを効率化・自動化するツールは?
コードレビューの工数を削減するにはツールの活用が有効です。代表的なものを紹介します。
Web上で利用可能な「GitHub」
GitHubは、Web上でソースコードを管理・共有できるエンジニア向けサイトですが、コードレビューに使えるプルリクエスト機能も備わっています。コードレビューを依頼できて便利です。
AIでコードレビューを自動化できる「Amazon CodeGuru」
Amazon社が提供するCodeGuruでは、AI(人工知能)を使ってソースコードレビューができ、バグや潜在リスクなどを検出してくれます。多くのデータを蓄積したAIがレビュアーとして検閲してくれるので、自動化に最適です。ただ、仕様や設計と適合しているかといった部分は手動でのコードレビューが必要です。
コードレビューの学習方法は?
コードレビューのやり方は現場で開発する際に、チームの中で覚えていくことが多いでしょう。また、昨今では、YouTubeなどの動画サイトやエンジニアのコミュニティサイトなども充実していて多くの情報が手に入ります。
ただ、コードレビューのやり方に限らず、ITスキルを身につける際、どうしても課題にぶつかってしまうことはありますよね。そこで、プログラミングスクールという手もあります。費用は掛かりますが、その分スキルを身につけやすいです。しっかりと知識・スキルを習得して実践に活かしたいという人はプログラミングスクールがおすすめです。
プログラミングスクールならテックマニアがおすすめ!
ITスキル需要の高まりとともにプログラミングスクールも増えました。しかし、どのスクールに通うべきか迷ってしまう人もいるでしょう。そんな方にはテックマニアをおすすめします!これまで多くのITエンジニアを育成・輩出してきたテックマニアでもプログラミングスクールを開講しています。
<テックマニアの特徴>
・たしかな育成実績と親身な教育 ~セカンドキャリアを全力支援~
・講師が現役エンジニア ~“本当”の開発ノウハウを直に学べる~
・専属講師が学習を徹底サポート ~「わからない」を徹底解決~
・実務ベースでスキルを習得 ~実践的な凝縮カリキュラム~
このような特徴を持つテックマニアはITエンジニアのスタートラインとして最適です。
話を聞きたい・詳しく知りたいという方はこちらからお気軽にお問い合わせください。