だらしないアナタのための静的OOPL

私は、基本的に組み込みソフトウェア開発ばかりで、大規模開発と言うのを殆ど経験したことがありません。唯一の経験が、これまで ASP (VBScript) で開発していた組織が ASP.net (C#) に移行する、そんなプロジェクトに駆り出されたことです。――が、結果は大失敗。

上のエントリは、そんな失敗経験しかない私のバイアスの掛かりまくった意見なのです。（だから論理的でない意見だなぁと自分でも思います）

しかし実はそのプロジェクト、将軍もダメダメでしたっし（幕僚本部にあたしが居たくらいだもん・・）、兵隊もダメダメにも程があるという感じでしたから、モデルケースとしては適当ではないと思います。今回のお話を語るに於いて、私は部外者もいいところです。（でもしゃべりたがりなので、ついつい(^^; ）

* * *

さて、別の話。凪瀬さんは、静的OOPL の大規模開発のメリットは、設計部隊と 猫の手部隊 の分離（設計部隊の敷いたレール上を走ることを 猫の手部隊に強制できる）を挙げておられますが、私はそれよりも、猫の手部隊の「最低ライン」を引き上げる効果の方が より美味しいものであるなぁ、と、件の失敗プロジェクトを通じて思いました。

どういうことかというと、（これまた凪瀬さんの言を借りれば）静的OOPL は「片付けを強制する言語」です。このギブスを枷と見るかガイドと見るかはその人次第ですが、「コーダー」軍団は まともにロジックを考えること（片付けすることが）が出来ない軍団ですから、片付けを強制される生活を送ることは良いことだなぁ、言うことです。なぜって、少なくとも「片付けするのが良いことだ」という認識が出来ると言う点で、偉大な一歩を踏み出しているからです。

* * *

たとえば・・・、

構造化(ここでは、構造化プログラミング・・と言う意味じゃなくってプログラムに構造を持たせる、、という広い意味で）の必要がないケース（例えば、凄い小さいプログラムとか）に対しても、構造化を強制させる言語と、そうしない言語があります。LL は後者で、何かをするには目的があり、目的にそぐわなければ手段を見直す、そんな合理的大好きっ子の嗜好にLLはマッチすることが多いです。

件の失敗大規模開発を始める際、あたしは組織の現状の開発を認識するためにと、既存のASP でのアプリケーション開発チームに 2ヶ月ほど参加させていただきました。そこで経験したのが「関数使うな！」です。関数を使うと処理があちこちにジャンプするため、コードを上から下に読んでもわからなくなるので「可読性が落ちる」から 使ってはいけないそうな(^^; ――それまでの私の経験からすると、どんなダメなプログラマでもそんなことは言わないわけで、信じられない事態でした。

で、こういうのがまかり通っちゃうのをみると、必ず関数/クラスを作らなくてはいけない言語というのは、意味があるんだなぁ、、と、しみじみ思うのです。

大規模開発を念頭に置いた言語では、きちんキチンを強制する変わりにうざったいのを良しとする。儀礼的で無駄が多いけれど、おかげで間違いも犯させない、そうすれば「最低」のラインを引き上げられるから、と、そんな感じ。そして 静的OOPL という方向性が大規模開発にマッチしてる（とされる）のは、コッチの指針に良く合うから、ということじゃないかな、というのが私の考えだったりします。

そして（ここからが重要で！）、そういう矯正をされつづけると、自ずと実力も向上するのです。もちろん駄目な方はどんな言語つかってもダメなのをつくるのですが、しかし、少なくとも「何が正しくてなにが間違っているか」が解るようになっただけで大進歩。決して 五十歩百歩なんかじゃない、としみじみ痛感いたしました。

「向上心のない初心者の集団」よりも「向上心のない中級者（の下のほう）の集団」の方が、断然マシ！・・・で、静的OOPL の場合、集団を後者に導いてくれる力があるような気がする。（これが本当ならとても美味しい事態ですよ！）

* * *

つまり静的OOPLは、下の方に設計をさせないのに役に立つんじゃなくって、下の方が設計するのに役に立つ、じゃないかな〜、と思う次第。しかも教育効果付き。

もちろん排他関係にあるわけじゃないし、結局は同じ事を言っているような気も、書き終わったらしてきたのですけれど(^^;