「開発現場で役立たせるための設計原則とパターン」をオススメできない理由

「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である

このエントリーは実況中継シリーズ「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴くに対する返答です。件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。

私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。そして発表者様のエントリーを読んでも私の感想は変わりませんでした。

まず、件のスライドにおける設計原則の解説自体には問題はなく、サンプルコード付きで解説していることは素晴らしいです。

問題は、設計原則の適用対象が生存期間が短いものになっていることです。これは、ここ20年ではもはや定説とされている「要件はよく変わる」「機能はよく変わる」という問題をそのまま受け継いでいます。つまり、この設計は要件変更に非常に弱い作りです。ただ、要件変更に弱くてもコストがペイする（ROIが企業としては問題ない）場合もあると思います。私はそのような場面についてはあまり興味はありません。私が興味があるのは、「変更につよい」とうたう設計とはなにか？という話です。

一応、記事中でも次のような説明があります

「問題によって適切な構造は変わる」

ただ、この文言が出てくるのはずいぶんと後半です。2/3はこれに反したような内容をつらつらと書いています。仮にこの文言が最も主張したい内容だったとして、つまりそれはどのように実践するのか？についてはまるで解決方法が提示されていません。これでは「この発表では考慮していませんが、考慮すべき大切なことがあります。（どうやるかは提示しない）」という発表になっています。なんの発表だったんだ。。。

発表の中にでてきた、コメントがどうこうとか、通知がどうこうとかってあきらかに機能の話で、その機能を構造化しても結局変更されるので弱いんですよ。もちろん設計は必要なんですけど、もっと重要な設計が先にあるということです。

まずは普遍的なモノゴトを対象に吟味して設計し、機能の設計はもっと力を抜いて設計したほうが良いです。

よく変更されるような振る舞いについては簡単に書き換えられるようになっているほうが楽だし、そのときに「この機能はこんなに重要だ！」という思い込みによる具象化と抽象化をするのは、いわゆる早すぎる最適化と同じ問題を抱えています。

私のバイアスの話

私はアジャイル開発やメッセージベースオブジェクト指向が好きです。ここの共通テーマは「決定を遅延しながら機能するネットワークを常に作り続ける」ことだと思っています。そして共通する課題意識が構造というのは人間が計画駆動で生活したいというためのフォースが働いているものであり、私はそれをもっと使いこなす必要があると考えています。（言い過ぎかもしれないけど、構造を決定する必要はほぼないと私は考えている節がある）少なくともIT業界でアジャイル開発の根本的な概念は広まっていて、要件はよく変わるし、見通せるものではないのだから、常に変化に対応しようとする話があります。よって、私はこの考え方に反しているとさきの記事を見て思ったのです。（記事の中で「常に考えよう」という姿勢はあるんですけど、対象があまりにも狭いという話です。）

おまけ

では、私は実践できているのか？というと、幾分かは出来ていると考えています。まだ道半ばです。その道半ばですが、何を考えてソフトウェア開発をしているのか？どのように要件を考えたり、設計をしているのか？というチャレンジの話を今度発表しようと考えています。公募制なので通るかわかりませんが。公募が通らなかった場合は別の機会に発表しようと思いますので、聞きたい人はお気軽にコメントなりTwitterなり教えてください。

confengine.com