ソフトウェアの保守性、信頼性のトレードオフ

本エントリは2007/11/19にここオルタナティブブログの私のエントリ)で公開済みのものである。

                                      • -

長期にわたる保守を前提としたソフトウェアを開発していく場合、保守性(拡張性)、信頼性のトレードオフが問題となる。保守性は長期的、信頼性は短期的な観点だといえるだろう。たとえば、プロダクトラインであったり、パッケージソフトウェア、Webで利用できるサービスや準パッケージ、組込み機器用等がその例だろう。

以前のリリース等で、十分にテストを実施でき稼動実績のあるコードをわざわざ改変しデグレード(デグレードについてはここに書いた)のリスクにさらすよりも、稼動実績のあるコードは改変せずにコードを流用して利用するほうが短期的(次のリリースの信頼性)にはメリットが大きい。しかしながら、長期的には類似のコードが分散してしまうため一見簡単な機能追加をしようとしても改変場所が多数あったりテスト規模が膨大になる場合がある。これを短期的な信頼性確保のために保守性が失われているというふうに考えることができるだろう。

商用開発で主に保守開発や派生開発(既存ソフトウェアに機能拡張していくタイプのもの)に携わっている方とソースコードメトリクスの話をすると、オープンソースソフトウェアとの比較が話題になることがある。オープンソースソフトウェアでは、どちらかというと長期的な保守性の視点にたった改変が多く、短期的な信頼性確保よりも優先されているように思う。私の経験でもオープンソースで新しいリリースでデグレードを何度か目にしたことがある。オープンソースソフトウェアと比較すると、商用開発では長期的な視点も大事であるが、まずは短期的な次のリリースの信頼性を優先することが多くなるものが割合としては多いだろう。

オープンソースソフトウェアが長期的な視点を大事にするもう1つの理由は、保守性の低いオープンソースは淘汰されやすいからだ。私自身もC言語のマクロ定義だらけのオープンソースソフトウェアを目にしたことがあるが、ソフトウェアとして非常に興味をもてるのだが、ちょっとしたbug fixをしようにも、なかなか手が出せなかった。

一般にはコードクローンと呼ぶ類似コード片もオープンソースよりも商用開発のほうが多くなる傾向にある。信頼性確保のため、既にきちんと動いている部分に手をいれないためにコードをコピーしながら機能拡張していく。結果として類似コードが増えるからだ。コードクローンについてはここここが詳しい。類似バグとの関係を書いたエントリがここにある。

このトレードオフを直接解決する手立てはそれほど多くないが、以下はそのうちのいくつかといえるだろう。

  • 一定の規模以内のソフトウェアについては、ソースコードの編集を中心に開発を進行していくタイプのアジャイル手法で、保守性を重視することを決めておく。
  • テストを自動化し、改変時には自動化したテストを実行する。ただし、テスト用のコードにも当然、保守性と信頼性のトレードオフは存在する。
  • 長期的視点に立ちソフトウェアの使用期限を設け(たとえば10年)、再設計やリファクタリングを計画に盛り込んでおく。保守性と信頼性のトレードオフの存在を受け入れる。主に信頼性を重視しながら進めていくが、何バージョンか後に保守性が開発効率に強く影響しはじめたころに一部の作り直しに着手する。