「追加開発時にデグレードが気になる」という相談

去年1年くらい（2007年）で昔の仕事仲間や大学のときの知人からプライベートな場で何件か相談を受けた。デグレードしないように改変したいという点で、内容はどれも似通っている（デグレードについてはここに書いた）。対象ソフトウェアも以下のようなもので似通っている。改版時に何か役立つものを知らない？という相談だ。

• 数年前くらいでいったん開発を終えた。
  当時の担当者が異動になったりして情報が少ない。
• 組織として「中規模」以下に位置付けられ、ドキュメンテーションや管理等、若干緩め。ソースコードへの改変のうち、ドキュメントに記録されていないものがある。
• ちょっとした機能追加をしたい、あるいは、今後の保守に備えて既知の潜在的な不具合を直しておきたい。

この状況で、抜本的、安全で低コストの手法があればいいのだが、そうそう簡単な方法はない。間接的に以下のような解決策に頼ることになるだろう。

1. より一層コストを積んで抜本的に修正する。コストは後で回収する。
2. 当該ソフトウェアがどの程度今後の保守に耐えうるのかを勘案し、作り直す際のコストを少しずつ貯めていく。たまった時点で抜本的に修正する。
3. 利用者にリスクを認識してもらい、現行のコストのままだと品質低下の可能性があることをまずは理解してもらった上で、リスクの低い部分から改版する。

1と2は先払いか後払いかという点が異なる。顧客や利用者にもよるが3のような耳の痛い話もしなければならないと思う。質問をしてきた何人かには上述のような回答をしたが、当然ながら不満そうだった。次善策として以下を伝えた。

• プログラミング言語によっては静的に制御依存、データ依存を解析するツールがあるのでその実行結果を参考にする。（わかるのは全てではないが、漏れをチェックするためにはそれなりに低コストで効果がある）
• ミドルウェア、エミュレータ、パケット解析等でログをとって、改変前と改編後で突き合わせ、デグレードしていないか調べる。
• アサーションやデバッガの条件つきブレークポイントを利用して典型的な利用方法でデグレードの確認をする。

これらだけで抜本的な解決ができるとは思えないが、何か気づきを与えることができたようだった。その際、「他にも同じようなことがあるから、匿名にしてエントリにするよ」と承諾を得て、このエントリになった。