デグレードを防止するためにやるべきこと

デグレードとは？
デグレが発生するメカニズム
影響調査が必要な個所
デグレを防止するためにやるべきこと
結論：デグレードを防ぐために、共通変数やモジュールの振る舞いの変化に着目しよう。

システム開発で、最もやってはいけないのが、デグレードだ。これをやってしまうと、お客さんは激怒する。お客さんが他のお客さんにサービスを提供している類なら、お客さんも、そのお客さんも、みんな激怒する。それだけ恐ろしいことだ。

やってはいけないのだが、何も考えずにソフトウェアを変更していれば、しょっちゅうデグレードは発生する。エンジニアをやっていれば、多かれ少なかれ、必ずこの言葉をどこかで聞くことになるはずだ。今回は、デグレードをどうやって防止するかについて整理する。

デグレードとは？

デグレード(以下、デグレ)とは、新しいバージョンのソフトウェアの品質が、以前より悪くなることを意味する。「リリース後に前の機能が動かなくなった」といった場合はデグレだ。筆者もデグレに悩まされてきた。不具合修正案件の場合は、わざわざ「デグレをさせないこと」というのを要件としていたぐらいだ。また、「デグレをさせないために、どのようなことをしようとしているか」を開発者に説明してもらっていたくらいだ。デグレのやっかいな点は、変更した箇所以外のところで不具合が出現する点だ。したがって、変更箇所を起点として作成したテストをすり抜けることが多い。

デグレが発生するメカニズム

なぜデグレが発生するのかについて整理する。デグレというのは、ある機能を変更することで、ほかの機能がその変更の影響を受け、結果として他の機能が動かなくなることだ。そのようなケースを整理すると、下記パターンとなる。

①変更により、他モジュールから参照されている共通変数の中身が書き換わった
②変更により、変更したモジュールのふるまい(戻り値)が変わった
③変更により、変更したモジュールのふるまい(速度低下)が変わった

①他モジュールから参照されている共通変数の中身が書き換わった

この場合は、2通りのパターンに分かれる。

・明示的に共通変数を書き換える場合

・意図せず共通変数を書き換える場合

前者に関しては、見ればわかるものであるので問題ない。後者に関しては、ソースコードを見てもすぐわからないので問題だ。たいていは別モジュールを呼び出したことにより、呼び出されたモジュールが共通変数を書き換える場合だ。意図せず共通変数を書き換えていないか、変更した際に使用するモジュールが何をしているのか、よく理解しておく必要がある。

②変更したモジュールのふるまい(戻り値)が変わったケース

このケースは非常によくあるケースだ。呼び出し元は振る舞いの変更など知らずに動作しているので、いきなりモジュールの戻り値が変わってしまうと、動くわけがない。従って、原則として、振る舞いが変わってしまう場合は、呼び出し元を全部調査して影響がないことを確認することとなる。

しかしながら、この作業はとてつもなくめんどくさい。ちなみに、筆者が関わった大規模プロジェクトでは、テキストエディタのgrep機能でモジュール名を調べただけで、数分かかることがあった。その後に絶望したのは言うまでもない。

③変更したモジュールのふるまい(速度低下)が変わったケース

このケースもよくある。呼び出し元は、呼び出し先のモジュールの処理が終わらないことを想定してタイムアウト処理を行うことがある。変更により処理が遅くなった結果、なんだか動きがおかしい、となることはよくある。