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

はじめに

id:Nagiseさんのエントリ
コードクローンと品質 - プログラマーの脳みそ
にて、コードクローンと品質についての論文が引用されていました。

この論文について、また少し違った視点から見てみようと思います。

信頼性と保守性はトレードオフなのか？

先のエントリに引用されていた論文はこちらになります。
コードクローンに基づくレガシーソフトウェアの品質の分析(PDF)
この論文に以下のような記述がありました。

コードクローンの生成は、信頼性の低下を抑える可能性があるが、一方では保守コスト増大の原因となりうるため、信頼性と保守性はトレードオフの関係にあるといえる。

また、こんなエントリもありました。
保守性と信頼性のトレードオフ：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ

長期にわたる保守を前提としたソフトウェアを開発していく場合、保守性(拡張性)、信頼性のトレードオフが問題となる。

ここに挙げられているように、信頼性と保守性はトレードオフの関係にあるのでしょうか？

暗黙のトレードオフ

信頼性と保守性がトレードオフとすると、それらは両立しないように思えます。果たしてそうなのでしょうか。

この式が成り立つ裏にはもう一つの要素が隠れていると考えました。それは『工数』です。つまり、信頼性(Reliability)・保守性(Maintainability)・工数(Cost)の3つのうち2つしか満たせない、という式になります。
※まるでCAP定理のようですが、この式にはCAP定理と同じ問題を含んでいると思われます。それは後述します。

トレードオフの例

先ほど挙げた式が成り立つのか、確認してみたいと思います。

1)信頼性・保守性を選択（工数を犠牲）
保守性を守るため、コードクローンを作らないのはもちろん、リファクタリング、ひいては設計の見直しを行うかもしれません。さらに信頼性も保証する必要があるため、試験範囲と量は大きくなります。結果、工数がかさむことになります。

2)信頼性・工数を選択（保守性を犠牲）
これは論文で挙げられたようなケースになります。
既存コードを残したまま拡張したり修正することで、既存コードの信頼性を落とさないですみます。また、信頼性の高い既存コードを基に作ることで新規コードの信頼性もなるべく落とさないようにします。
他にはバグ修正を場当たりな方法で修正するケースも含まれるでしょう。コードの改修が小規模で済む場合、改修による影響範囲を狭めたり工数を削減することができます。
ただ、いずれのケースにおいても重複コードが増えたり、場当たりな修正がその後の拡張をしづらくしたりと、保守性は犠牲となります。

3)保守性・工数を選択（信頼性を犠牲）
これは設計・実装を大きく見直したのにもかかわらず、試験を十分に行わないケースが該当します。設計・実装の変更が保守性に良い影響を与えるかもしれませんが、試験が不十分なため信頼性は犠牲となりました。

いずれも比較的現実的なシナリオで成り立つといえそうです。

実際の開発現場でのトレードオフ

それでは実際の現場ではどうなるのか。
通常のアプリケーション開発であれば工数は非常に重視されます。時には信頼性や保守性よりも優先されるでしょう。となると、先の式は信頼性・保守性のトレードオフの式へと簡略化されます。つまり、先の論文やエントリで主張している事に一致しそうです。

この式の問題点

ではこの式のどこに問題があるのでしょうか。それはCAP定理と同じく
12年後のCAP定理: "法則"はどのように変わったか

この公式は3つの属性の緊張関係を過度に単純化してしまうからです。過度の単純化は問題です。

ということです。

工数は犠牲になるのか

工数について考えてみましょう。工数は信頼性と保守性を両立させるために本当に犠牲となるのでしょうか？それは現在において必ずしも成り立たないと考えます。
今では優れた開発ツールを利用できます。言語自体の進化もあります。また、『リファクタリング』に代表されるような技法の確立もあります。これらを適切に利用することで、信頼性と保守性を維持しながら工数の増大を抑えることが可能かもしれません。

（工数を選択したとき）信頼性と保守性はトレードオフか

この二つの相関関係について論じた論文がないか調べたのですが、私の調べた範囲では見つかりませんでした。なので、ここでの話は個人的な経験則となります。
信頼性も保守性もですが、その評価はあくまでその時点のコードに対してのものとなります。つまり、その時点では信頼性が高くとも、その後の改修などを経て信頼性が低くなることはあり得ます。
そして長期的視点に立った時、信頼性と保守性は正の相関関係にあると感じています。保守性が高ければ新たなバグを埋め込む確率も低くなり、結果として信頼性を維持することに寄与するからです。
なので、論文にあるように改修した時点であれば信頼性と保守性はトレードオフに見えるかもしれません。ですが、長期的な視点に立った場合、それは必ずしもトレードオフと言えないのではないでしょうか。

まとめ

一言でまとめるならこの言葉となります。

過度の単純化は問題です。

実際の開発ではありとあらゆるファクターが存在し、影響しあいます。その一面だけを切り取って把握しようとすることは極めて困難です。信頼性と保守性がトレードオフにあるかはその状況次第でしょう。
ただし、これはソフトウェア工学を軽視するものではありません。法則とその背景にあるものを理解し、適切に利用することが大切ということです。

［論点3］どんな開発手法を適用すべきか | 日経 xTECH（クロステック）

これに対して東証は「コードクローン（記述の重複）を含むプログラムは、含まないプログラムと比較して信頼性が高いことが定量的な研究で裏付けられている」と反論した。

この反論がその研究結果の背景まで理解したうえで主張したのか。気になるところです。

参考

文中で紹介した『リファクタリング』です。ご参考までに。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)