プログラミングの話。経験的に、中核となる仕組みが頑健に作られていると、周りを取り巻く仕組みをスムーズに作れることが多い気がする。つまり、アドホックに拡張していったシステムよりも、まずきわめて強固な仕組みを作って、残りの機能はそのDSLであるかのように振る舞わせるようなシステムのほうが良いということ。それは当然ですねという感じだけど、経験がそれを裏付けるなという体験があった、という話です。
どうしてこのようなことを思ったかというと、最近書いているzmmという動画作成支援ツールがまさにこの例に合致しており、コアコンセプトの実装が済んだあとはだいたいそれをうまく扱うだけで周りの機能を作れている、ということがあったため。
zmmではコンテキストという概念を採用しており、キャラクターが喋っている各セリフ時点での何らかの文脈を抽象化している。そして、動画の生成元となるXMLファイルの各要素からコンテキストが生成される。そしてコンテキストは上位から下位の要素へと伝播していき、上位と下位のコンテキストが衝突するときはうまく合成するようにしている。 このコンテキストがzmmのコアコンセプトになっており、最近ソースコードの表示機能を追加したときも、コアコンセプトにはほぼ手を加えずに、コンテキストにフィールドを生やすだけでだいたい終わった。 どうしてこの仕組みが頑健かというと、まずXMLはそもそも木構造なので扱いやすくもともと頑健で、次にコンテキストはMonoidとして実装したので数学的な頑健さを与えられた状態になって、最終的に自然と頑健な仕組み同士が組み合わさって頑健なコアコンセプトになったのだと思う。
これを一般化すると、良いソフトウェアを書くためには、問題領域をうまくモデル化できるコアコンセプトを頑健に作成し、そこの品質を上げることで全体の開発効率が良くなるだろうと思う。さらに、コアコンセプトをモデル化する場合は既に頑健なことが分かっている構造や数学的枠組みの力を入れてやることができないか一考するべきである。例えばScalaにはCatsという型クラスを扱うためのライブラリがあり、自然にプログラムに頑健な数学上の構造が持ち込まれる。前述したMonoidとしての振舞いも、このCatsによって力を発揮できている。
一言で言うと、骨太であれということ。中心が骨太でなければ、どんなに頑張って周りの仕組みを実装しても、それに耐えられずに崩壊するか、脆弱な骨組みをサポートするために周りの仕組み自体が骨の代わりに振る舞うようになって極度に柔軟性が損なわれる。なので、何をしたいかよりも先にモデルを考えるのがやはり正道っぽい。