勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

Visual Basicとドメインモデル貧血症とその他の影響

重い腰を上げて、実践ドメイン駆動設計を読み始めているのだけれども、第1章でVisual BasicがDis(?)られていて面白かったのでそのメモ。なお該当箇所はGoogleブックスで立ち読みできるようなので興味があれば以下リンクから該当箇所を読んでみると良いと思う。なお、単なるあるある話であり、オチはない。

それ以外にも、昔からのの影響がある。古代のMicrosoft Visual Basicが開発者におよぼした影響は大きい。別に、Visual Basicの言語そのものや統合開発環境(IDE)自体を悪く言うつもりはない。あれはあれで、たしかに生産性は高かったし、いろんな意味で業界的には役立った。もちろん、Visual Basicの影響をまったく受けていないという人もいるだろう。しかしVisual Basicは、直接・間接を問わず、ほぼすべての開発者たちに何らかの影響をおよぼしている。
実践ドメイン駆動設計 第1章 DDDへの誘い 貧血を起こす理由

この後同書では、VBからの影響として「プロパティとプロパティシート」の話となるのだけど、なるほどという気はする。これに限らず「古代のMicrosoft Visual Basic」の影響はもっとあると思うのだけれども、こういった事を深堀りしている研究とか、ないかな・・・。

Visual Basicと設計書の呪い

ドメインモデル貧血症」といった高尚な影響に限らず、思い返すとVisual Basicの呪いはいろいろとあると思う。現代でも時々目撃するものとして「設計書の呪い」と呼ぶようなものはある。

  • 一種の画面設計書なのだけれども、VBFormの開発に最適化されているようなフォーマット
  • 往々にしてExcel方眼紙
  • VBFormのアプリのプログラムを極力文章に落としたような内容になっている。つまり設計書という名前になっているけど、事前設計時点ではすべて埋めることは困難なレベル。しかしコーディングに着手する前に作成を求められたりする
  • この状況を逆手にとって、仕様書を逆生成するツールが商用/非商用で世に溢れる
  • 恐ろしいことに、この時代に定められた設計書のフォーマットだけが「標準化」として生き残っていたりする。開発言語を問わず適用するルールになっていたりして・・・
  • 設計方法論なぞないので、こういった設計書を誤って利用することにより、システム全体の設計が不適当になったり・・・