積読状態だった、「オブジェクト指向入門」（第１版）Bertrand Meyer著の読書記録です。
要約と自分なりの解釈を残しておけば教育・指導を行う際にでも役に立つかなってことで。
(第２版に手を出すガッツはない・・・)

1 ソフトウェアの品質とは

品質の高いプログラムとは何だろうか？

それを左右する品質要因には、ユーザから認識されうる「外的品質要因」と、ユーザからは認識されない「内的品質要因」がある。ソフトウェアは最終的には外的品質要因の充足を目指さなくてはならないが、そのためには「内的品質要因」を満たす必要があるのだ。

この本の大部分は「内的品質要因」について書かれているが、その前にゴールとなる「外的品質要因」にはどのようなものがあるか？主要なものをあげてみよう。

仕様通りに動くということ。仕様そのものが妥当かどうかは別として。

想定外の異常な状態でも機能すること。または破滅的な状態（データを壊しちゃうとか）を避けて安全に停止などすること。

誤った形式のデータが送られてきたら？ディスク容量が不足していたら？オフラインになったら？これらを「想定外」とするのではなく仕様として定義するならば、これは「正確さ」の問題になる。だが常に想定外のことは起こるだろう？

本来、ソフトウェアはハードウェアよりずっと変更することが容易なはずだ・・・本当にそうか？でっかいシステムの一部を修正するなどということがお気軽にできるだろうか？完成したはずのプログラムを修正しなければならない場合はよくある。

ここは「修正しやすさ」と言い換えたほうが正確じゃないかと思う。拡張に限らず、バグを直したときに他のバグを生んでしまわないかをあまり心配せずに済むかどうか、という観点でもある。

拡張性を向上させるカギは以下の2つ。これらは本書の主要なテーマとなる。

ソフトウェアの部品を使いまわせること。当然、使いまわせればコストの削減につながる。

他のソフトウェアとの協調ができるか、ということ。バイナリデータではなくテキストデータを使おう。XMLやJSONにしておこう。APIを提供しよう。

1.3 ソフトウェアの保守について

ソフトウェアの品質について考えるなら、開発段階しか考慮しないならそれは片手落ちだ。統計によればソフトウェアにかかる費用の70%は保守に費やされている。

本文で引用されてる統計は非常に古い（1979年）が、状況は現在もさほど変わってはいないだろう。ソフトウェアは完成した後の方が手間がかかる（ソフトウェアに「完成」という概念があればの話だが）。