どうやら自分が興味があるのは「ソフトウェア設計」というより「変更容易性」のようだ

「ソフトウェア設計」に強くなりてぇ... と思ってここの所その手の書籍に改めて色々手を出していたのだが1つのことに気がついた。

これ「ソフトウェア設計」の話じゃなくて「変更容易性」の話だ...

正確には「ソフトウェア設計」がカバーする要素の1つであるところの「変更容易性」に焦点を合わせているものが多い。 この辺りはそれぞれの書籍において最初の方に記載されている。 例えば以下のような感じ。

考えにくいことですが、一度書かれたら、このアプリケーションは永久に変化しないとしましょう。この場合、設計を気にする必要はありません。
...
変更の必要性こそが、設計を重要にするのです。
(オブジェクト指向設計実践ガイド)

ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである
(Clean Architecture 達人に学ぶソフトウェアの構造と設計)

それは「設計」に問題があるからです。設計とは、ソフトウェア全体をすっきりした形に整えることです。どこに何が書いてあるかわかりやすくし、修正や拡張が楽で安全になるコードを生み出すのが設計です。
オブジェクト指向でソフトウェアを設計する目的は、こういう変更の大変さを減らすことです。どこに何が書いてあるかをわかりやすくし、変更の影響を狭い範囲に閉じ込め、安定して動作する部品を柔軟に組み合わせながらソフトウェアを構築する技法がオブジェクト指向設計です。
(現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法)

これらの記載だけ抜き出してみると「ソフトウェア設計の目的 = 変更容易性」であるように錯覚してしまう。 が当然それは違う。要件/パフォーマンス/セキュリティ等、ソフトウェア設計には他にも重要な観点が多く存在する。

似たようなことは書籍にも記載が存在する。

本書では、「ソフトウェア設計」のうち、どんなアプリケーション機能を提 供するかと、具体的にどんなミドルウェアアルゴリズムで機能を実現するか を除いた領域、ソフトウェアのアーキテクチャ作りに着目します。
(ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用)

ソフトウェアにおける設計とは、なんらかのソフトウェア品質特性の 向上を促進するためのしくみをつくることです。たとえば性能効率性はパフォー マンス性能を表す品質特性であり、性能効率性を上げるにはパフォーマンス設計 をします。 では本書での設計は、主にどの品質特性の向上を狙ったものでしょうか。 ... 保守性の中でも、特に 変更容易性の向上を目的にした設計手法 なのです。
(良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方)

どうもソフトウェア設計について学ぼうとすると、この手の「変更容易性」に焦点を当てた内容に行き当たりやすいように思う。 これはある種のバグというか適切でない情報の偏りのようにも感じてしまうが、まぁ認識していれば大きな問題ではないか。 (もしくは私が「変更容易性」に興味があるため、そちらに引き付けられているだけかもしれない)

いずれにせよ私が興味を持っている分野は、「ソフトウェア設計」というより「変更容易性」と表現するほうが適切そうだ。 これまで個人的に学んできた内容も結構そちらに偏っている。 (ソフトウェア設計原則とかDDDとか可読性の向上とかデザインパターンとか結構違うけどモデリングとか、RailsでいうところのFat Model問題とか、ドメインロジックどこに置くねんどう構成すんねん話とか去年ぶっ刺さりのSustainable Railsの本とかAPoSDとか...)

今後は意識的に「変更容易性重視ビルド」を組んでで戦っていきたい、という決意表明。 はぁ、たったこれだけの内容を吐き出すのに本当に時間がかかってしまったなぁ...