EurekaMoments

ロボットや自動車の自律移動に関する知識や技術、プログラミング、ソフトウェア開発について勉強したことをメモするブログ

ソフトウェア開発におけるレビューについての勉強メモ

目次

はじめに

ソフトウェア開発においてバグを発見するために、そのソフトウェアのコードレビューやベンチテストは必要不可欠な作業です。僕の普段の開発業務でも、仕様や設計、コードレビューを行うステップがあるのですが、どうも最近、見つけられたはずのしょーもないバグが「今更?」って感じのタイミングで見つかることがあるなぁ、感じています。
バグを見つけられなかったことはしょうがいないのですが、今後また同じようなことで悩まないためにも、自分達のレビューのどこに問題があったのかを考えなければなりません。
今回の記事では、正しいソフトウェアレビューについて学び、それを参考に自分の開発業務におけるレビュー改善について考えてみようと思います。

参考文献

今回はこちらの記事を参考にさせていただきました。レビューとは本来どういうものであるのか、その中で自分達が普段行っているレビューはどれに当たるのかを考えることが出来ました。

qiita.com

また、レビューを含めソフトウェア開発とは、一人ではなくチームで行うことがほとんどだと思います。その際に、チームでのバージョン管理やテスト、レビューの仕組みに不備があると開発者同士の間でトラブルが起こってしまいます。以下の書籍では、チーム開発における便利なツールやメソッドを豊富に紹介してくれているので大いに参考になります。

レビューの種類と目的

「レビュー」と言っても実は下記の表のようにいくつかの種類に分かれるようです。 f:id:sy4310:20180930121434p:plain ここでまず気付いたのは、表の一番上にある教育レビューという文化が僕の職場にはないなということです。レビューをして欠陥や間違いを見つけるためには、まずは正しい形、本来のあるべき形を把握しているべきだと思うのですが、それを促すのが教育レビューなのでしょう。

改善点①: 新規開発機能の教育レビュー不足

ここ最近で何件かの細かいバグ(コード量は少ないけど、性能等への影響度は大きい)が僕の実装したソースコードで見つかっている訳ですが、それらは全て既存機能の修正ではなく、そのプロジェクトのタイミングで新規開発される機能に関わる部分ばかりでした。
その新規機能には、チームとしてあまり馴染みが無い技術が利用されているのですが、今思い返せばその辺りの説明を事前にしっかりとやっておくべきだったと思います。そのため今回見つかったバグは、事前説明が不足していたので見落とされた、あるいは良く分からんからテキトーにレビューされたかのどちらかでしょう。

「最悪を最初に」を基本としたレビュー

手戻りのコストが高くついたり、失敗するリスクが高い部分から優先的にレビューしていくというのが大事のようです。他にも下記のような選択基準が挙げられています。

  • 複雑度が高いコード
  • バグの発生率が高いコード
  • 中心となるコンポーネントの中核コード
  • 信頼できないやつの書いたコード

改善点②: 簡単なところからレビューを始めがち

レビューすべき項目が沢山ある場合、とりあえず簡単なところからレビューをして、とにかく全体の数を減らそうとしてしまいがちです。それでも数が多いのでなんやかんやで時間が掛かり、後回しにしていた複雑なコードのレビューに掛けられる時間が少なくなってしまうのがオチです。
こうなるとテキトーに流したようなレビューで済まされてしまうので、見つけられたはずのバグを見落としてしまうといった問題に繋がってしまいます。

改善点③: コードレビューがメールベース

今の職場でのコードレビューは基本的にメールで依頼を出して、そのレビュー結果もメールで受け取ります。その結果を確認して、指摘があれば対応するのですが、その時に自分が本当にレビューして欲しかった部分が漏れている可能性もあり、バグの発見が遅れる原因になり得ます。
それならば、多少時間や人数を掛けてでもコードレビューミーティングを開催して、顔を突き合わせながらレビューするべきかもしれません。

レビューとインスペクション中の指針となる原則

  • エゴは入り口で預けてしまうこと
  • 作者ではなく成果物を批評すること
  • インスペクション中に問題を修正しようとしないこと
  • インスペクションの会議は最長2時間までにすること
  • パフォーマンスやわかりやすさに影響を及ぼさない限り、スタイルの問題は差し控えること
  • 早い時期から頻繁に、公式でも非公式でもいいからレビューを行うこと

改善点④: 公式のタイミングでしかレビューをしない

今の職場での公式レビューのタイミングは、仕様レビュー、設計レビュー、コードレビューとあるのですが、改めて確認するとコードレビューが一回しかありません。この頃にはコードが書き上がっている状態なので、細かいバグなんかは埋もれてしまって非常に見つけにくくなってしまいます。
それよりは、非公式でもいいからコードをある程度書いたらレビュー、また少し書いたらレビューといったように、頻繁にレビューを挟めば小さなバグも早期に発見できるようになると思います。

まとめ

ソフトウェア開発におけるレビューについて学び、自身の開発工程を見直したところ、下記の改善点が見つかりました。

  • 新規開発機能の教育レビュー不足
  • 簡単なところからレビューを始めがち
  • コードレビューがメールベース
  • 公式のタイミングしかレビューしない

これらをいきなりがらっと改善することは難しいですが、自ら率先して少しずつ改善、浸透させていけるように活動していこうと思います。