読者です 読者をやめる 読者になる 読者になる

フリーランスITエンジニアのすすめ

フリーランスITエンジニアの働き方についてのブログです

抽象度をどこまで上げればいいのかということと、オブジェクト指向的アプローチがSIで流行しない理由

以下のブログを読んでみて、自分もポエムを書いてみたくなりました。

watanabek.cocolog-nifty.com

blog.hidenorigoto.com

 

プログラムって、機械と人間の両方が読むものなんですよね。ですので、そこには表現の抽象度という概念があります。機械よりのものは抽象度が低いとし、人間よりのものは抽象度が高いとされています。

 

で、この抽象度というものを、どのレベルに持っていけば、みんなが幸せになれるのでしょうか。

抽象度を極端に下げていくと、機械語とかアセンブリになるんですが、それはあまりにも人間側に都合が悪すぎて生産性が低くなってしまいます。なので、一般的な業務システムなんかはJavaとかで作るのが普通ですね。

これはプログラミング言語レベルの抽象度の話ですが、プログラムの構造自体を工夫して抽象度を上げていこうという考え方もあります。

オブジェクト指向分析設計とか、今流行のドメイン駆動設計がそれにあたります。業務の言葉を使ってプログラムを書いていったり、プログラムの作りを業務のモデルと繋がるようにしようとする考え方ですね。

 

一般的に、この抽象度というものは高くなればなるほどいいと思われています。たしかに、プログラム自体が実際の業務の構造を表現していた方が、わかりやすいと思います。

 

しかし、SIの文脈でいうと、これは微妙かなと思うんですよね。どこまでも抽象度を上げていけば、プログラマがハッピーになるかというと、そうでもないような気がします。

だって、そもそもの話ですが、プログラマって業務わかっていないですからね。

SIのプログラマが読む詳細設計書は、完全なシステムの処理ベースで書かれていますし、業務色が完全に抜けてしまっています。要はトランザクションスクリプトです。

その状態でプログラマが、やれドメイン駆動でやるとか言っても、まず、インプットの詳細設計書が抽象度が低すぎちゃって、そこから抽象度を上げる方向に逆翻訳をしなきゃならなりません。

プログラマって、SIプロジェクトの中でも、抽象度が低いレベルの仕事を担当する人たちなので、一概に、抽象度を高めて、かっこいいプログラムを書く方法を教えても、彼らにとって豚に真珠のような気がしてなりません。

 

オブジェクト指向分析設計が全く流行しなかったのって、このあたりが原因じゃないかと思うんですよね。

まぁ、今は、オブジェクト指向分析設計は完全に死語となってしまって、ドメイン駆動設計の時代ですが、10年後、それがどういう文脈で語られるものになるのか、すごく興味がありますね。