CodeZine(コードジン)

特集ページ一覧

アプリケーション開発で質の高いコードレビューを実現するためのポイントとは?【前編】

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/08/27 20:30

 AWSでは、デベロッパーが持つ悩みや不安に対する課題解決のヒントとなるような、AWSのクラウド活用を学ぶことができる公式ウェブマガジン「builders.flash」を運営しています。今回は、質の高いコードレビューについて解説する記事の一部を、builders.flashでの公開に先駆けて一足お先にお届けします。(編集部)

  • 著:森崎 修司(名古屋大学 大学院 情報学研究科 准教授)

 コードレビューはソースコードを目で追って問題がないか確かめる活動です。自分の書いたコードを他の開発者に確認してもらったり他の開発者が書いたコードを自分が確認したりします。そのほかにも、他のメンバーが書いたコードを理解したり、代替案を考えたりすることが目的である場合もあります。本記事では、2 回にわたって、これらのうち問題を見つけて指摘(修正)することをコードレビューの目的として、そのためにどの箇所を見てどういうふうに確認すべきかを説明していきます。

*本記事では、レビューで指摘するものを問題と呼びます。代表的な問題はバグや欠陥ですが、指摘する時点ではバグや欠陥とは言えないものの将来引き起こしやすくなっているものを総称して問題としています。

コードの読み進め方

 問題がないかどうかチェックするために、確かめる箇所と確かめかたをコードの「読み進めかた」と呼びます。仕様との不整合をコードレビューで確認することは、多くのコードレビューにあてはまると思いますので、これを具体例として見てみましょう。

 あっさりとしていますが、この「仕様」に該当する部分を仕様から取り出し、対応するコードを確認します。

 もう少し具体的に、独自にオンラインショッピングサイトを開発している場合を考えてみましょう。仕様に「会員ステータス、買い物の総額、キャンペーンといった条件で送料を無料にする」といった部分があるとします。これらを実現しているコードを確認して、条件を満たしていれば送料が無料になるような実装になっているかどうかを確かめるといったように確認していきます。このとき、上の「確かめる箇所」と「確かめかた」は以下のように具体的に書けます。

 確かめる箇所としてプロダクトコードを前提としましたが、テストコードがあれば、テストコードも確認する箇所に含まれます。

 プロダクトコードであれば、その箇所が期待通り実現できているかどうか確かめます。テストコードでは、そのテストでバグがみつかるかどうかを確かめます。確かめかたは、送料無料の条件が正しく反映されるかです。同時に条件がそろっていなければ送料が加算されることも確かめます。

 仕様として明示はされていないけれど、実現する必要のあるものを暗黙の仕様と呼びます。これも同じように確認しなければなりません。オンラインショッピングサイトの商品検索機能として

 「検索キーワードを含む商品の一覧を表示する。1 画面に表示する結果は30 件とする」

といった仕様が明示されているとします。このときの暗黙の仕様として

 「検索結果が表示されるまでの時間は長くても数秒程度にする」

があります。表示に時間がかかるとユーザーがその機能を使わなくなるからです。この暗黙の仕様をあるべき姿と考え、確かめる箇所と確かめる方法を考えてみましょう。

※この記事で紹介したサービスの資料をダウンロードいただけます。資料は会員の方のみダウンロードしていただけます。



  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • builders.flash 編集部(builders.flash ヘンシュウブ)

     builders.flash は、日本のデベロッパーの皆様へ向けて、実践的なクラウドベストプラクティスを身近なテーマから解説する記事や、幅広い開発インタビューをお届けする AWS のウェブマガジンです。

バックナンバー

連載:選り抜き!「builders.flash」
All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5