僕がCOBOLから学んだこと
SAStruts＋DBFluteでの開発が終わり、またCOBOLで書かれたシステムの保守が始まる・・・。
あぁ、楽しかったSAStruts、楽しかったDBFlute、楽しかったJava。
ということで、この辺りで一度、COBOLから学んだことについてまとめてみようと思う。
僕が今、主にかかわっているシステムはクライアント側がVB(Windows)、サーバ側がCOBOL(UNIX)で出来ている。そして更にバックボーンには、メインフレームが構えている。メインフレーム側の構成は主にPL/1＋JCLで、もちろんDBは階層型だ。
そんなシステムを２年近く保守してきた中で気付いたことを書いて行こうと思う。
カプセル化やスコープの重要性
今更何を言っているのかと思う方もいると思うけど、マジなんだ。僕が初めて学んだ言語はC言語でそれからC++、Javaと続き、その後LL言語にも手を出し始めた。C++を始めた時に幾つかオブジェクト指向の参考書を読んだけど、必ずと言っていいほどカプセル化の話が出てくる。しかし、知識としては理解できても体感として有難みを感じることは、あまり無かった。なぜなら、C言語を使った場合でも、ファイル分割やらスコープやらをある程度意識して組めばカプセル化、カプセル化とギャーギャー騒ぐほどの事でも無いだろうと思っていたからだ。
・・・しかし、僕はCOBOLに出会った。それは衝撃的な出会いだった。
全ての変数がグローバル。COPY句で定義された巨大な構造体の様なもの。そしてIFとMOVEで８割が構成されている巨大なコード*1。そこにはヒープ領域もスタック領域も無かった。もちろんクラスやスコープだって無い。そんなCOBOLのコードを修正することで、僕はカプセル化やスコープの重要性を初めて体感出来た。
言語の構造は言語の主とするデータ構造に似る(事が多い)
これもCOBOLをやっていなかったら体感できなかったと思う事。
COBOLの場合のデータ構造はCOPY句で定義された構造体と階層型のDBでロジックはメインとサブ（関数）のモジュールで構成されていて、同じサブが使い回しされる事はあまりない。
オブジェクト指向の言語だとデータ構造はクラスでリレーショナルDBを使う事が主流だ。ロジック部分もクラスで書かれ色々なクラスが連動して動く。O/Rマッパの話をするときにインピーダンス・ミスマッチの話とかが出ることもあるけど、やっぱりオブジェクト指向のクラスとリレーショナルDBのエンティティは似ている。
JavaScriptの場合なんかもロジックをJSON的に書くことが出来るし、Lispの場合は言わずもがなだ。
じゃあ、次の時代はというとやっぱりクラウドなんかなー。言語の仕様としてスケール関連が含まれていたりするんかなー。まぁ、僕は言語をツールとして使う側の人間なのでこの辺りの勉強はもう少し後でいいやと思っている。
こんな感じで言語の構造は言語の主とするデータ構造に似る(事が多い)とCOBOLをやった事で気付く事が出来た。
上の世代のプロマネの考え方
実はこれがCOBOLから学んだ一番大きな利益だと思う。とあるJava(Web)の案件でスケジュールがかなり遅れている事があった。致命的なレスポンスの問題や大幅な仕様変更も抱えていた。その時僕はPGの立場でアサインされていたのだけど、プロマネから必要ならPGを追加すると言われた事があった。もちろん、僕は断ったのだけど。
このPGを追加するという判断もCOBOLをやると多少理解できる。COBOLで書かれるプログラムは、バッチ処理が多くてINとOUTがハッキリしている事が多い。だからいざという時に人海戦術で何とかする事が出来る可能性が高い。Java等の場合でもINとOUTはハッキリさせないといけないのだけど、その粒度が細かい事や単純なバッチ処理では無い事が人海戦術をとる事を難しくしている。COBOLの場合は、その粒度がかなり大きいことや一方通行の単純なバッチ処理が多いので圧倒的に人海戦術が使い易い。だから上の世代のプロマネはPGの追加という判断を行うのだと思う。
確かにCOBOL時代のコーディングは簡単だったのだ。しかし、その感覚を未だ引きずっているから、まだコードもまともに書けないSIerの新人に1年目やそこらから企画や設計をさせる*2。結果、今のSIerは技術が空洞化している。特に30代の中間辺りはかなりヤバい人が目立つ。この技術がスカスカのSE(自称)からは距離を取った方が良いというのもCOBOLが教えてくれたことの一つだ。
まとめ
最後にPGとかSEでなくて、プログラマとしての立場からまとめると、
COBOL=飯の種
それ以上でもそれ以下でもない。COBOLは何の感動も生まない。
さて、Python＋Google App Engineでアプリでも作るかな。
