オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

保守性と信頼性のトレードオフ

»

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

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

商用開発に携わっている方とソースコードメトリクスの話をするときなど意外にオープンソースソフトウェアとの比較を中心として話題にされることがある。オープンソースソフトウェアでは、どちらかというと長期的な視点にたった改変が多く、短期的な信頼性よりも優先されているように思う。私の経験でもオープンソースで新しいリリースでデグレードを何度か目にしたこと
がある。オープンソースソフトウェアと比較すると、商用開発では長期的な視点も大事であるが、まずは短期的な次のリリースの信頼性を優先することが多くなるだろう。

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

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

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

  • 規模を限定すればXPやアジャイルに代表されるソースコードを中心に進行する手法で、保守性を重視することを決めておけば、有効に働くだろう。
  • 主に単体テストが対象となるが、テストの自動化も有効に働くだろう。ただし、テスト用のコードにも拡張性の保守性のトレードオフは存在するため、過度の期待はできないだろう。
  • ソフトウェアの使用期限を設け、再設計やリファクタリングをある程度計画に盛り込んでおく。トレードオフの存在を受け入れ、透明性のある意思決定にしてしまうという考えである。透明性のある意思決定に関する過去のエントリはここを。
Comment(0)