ソフトウェアの実装において、拡張性をどの程度考慮すべきか

設計・実装を進めていると「ここはこうしたほうが後々便利かも」と思うことはよくある。

今回は現在開発しているシステムのドメインモデルのうち、一つの概念が複数の型とふるまいをとるクラスを設計していた。インターフェイスや継承などでよく実装されるパターンで、ドメインの表現的にも明確に分類すべきものだった。そこで自分は教科書通り継承を使った実装をした。

DDD的にも教科書通りであり、ある程度正しいコードだと思っていた。そんなつもりで残したコードをレビューで「継承はなくし、単一のクラスで表現したほうが良いのではないか」という指摘をもらった。

どういうことだろうと思い、自分の胸中をそのまま言葉にしてみた。

「自分は拡張性を見込める場合は実装に落とし込んでしまいがちだが、今回のように、やめておいたほうがいいのではないかという指摘を受けることがままある。教科書的にも正しく、後々便利なはずなのに、なぜなのか？」

その人曰く「維持が大変そう」ということだった。

ビジネスの世界では常に「納期」と「コスト」の問題が付きまとう。確かに拡張性があるに越したことはないが、そこに拡張性があったとして「それが全体にどの程度の利益をもたらすか」「逆に拡張性の高さで得られる利益を維持コストが上回る事がないか」「拡張性を上げたことによる設計の複雑さが利用者に困難を強いないか」等々、様々な面を同時に考慮する必要がある。その見積もりが外れてしまうと、製品の品質が高くても納期やコストを圧迫することになってしまう。結局QCDのバランスに行きつく。

このあたりは定量化が非常に難しく、経験に頼らざるを得ない（そのレビュアーも「難しいところで、感覚は人それぞれ異なる」と言っていた）。

SWE7年目にしてこのあたりの肌感が薄いのは若干焦りを感じるが、それを得るには、やはり手を動かし続けるしかない。その代わり趣味の世界では、こだわってもいいだろう。