開発言語と、通販対応配送センターERPの開発者の視点を中心としたコラムです。

自分でフレームワークや開発言語を作る体験から考えるメリットとデメリット

»

 自分は、Alinous-Coreという言語の作者でありますが、これを作った理由は、自分で技術の基礎的な部分をコントロールできるからです。新しいフレームワークとかも、勉強しなくてはいけない部分が多くあると、コントロールするために蓄積したスキルが役に立たなくなってしまいます。

 ですから、勉強をあまりしなくていいように考えて作ったのですが、かえって、それを作るのにたくさん勉強や作業をことになってしまいました。

 結論から言えば、勉強する総量を減らすためにフレームワークや開発言語を作るわけですが、それには最初にまとまった時間と作業の投資が必要です。

 でも、最終的にはいろいろ時間と作業を投資して良かったと思っています。筆者の場合は言語を自作する場合には、次のことが主なハードルになりました。

■「ドメイン特化型言語」を作るハードル

 自分にとっては、オブジェクト指向はすごく複雑で、なかなか馴染めませんでした(といいつつも、Alinous-Core本体やEclipseのエディタやデバッガなどはオブジェクト思考で書かれています)。

 そもそも、やることが多いのです。いろんなBeanを作るのが面倒だったり、あとで変更がやりにくくなったり、動的なものを作るのに特別な工夫が必要だったりします。むしろ、普通にWeb-DBアプリケーションを開発する上では、そういう工夫から解き放たれたいと思うことがとても多かったのを覚えています。

 また、自分にしか分からないような、複雑な仕様にしても分かりにくいので、JavaScriptとSQLとHTMLさえ分かれば、あとは適当に書ける言語を目指しました。

 が、しかし、このためにとんでもなく勉強や作業をすることになってしまいました。HTMLは、普通にHTMLなのでいいのですが、JavaScriptとSQLという性質の違う言語が同じスクリプト上に出てくると、普通にコンパイラ生成用のJavaCCを使うだけでなく、一部、JavaCCの中身も変えないといけなくなりました。

■チューニング系の自動化のハードル

 よく、JavaでJDBCを利用してSQLを発行すると、プリコンパイルして実行するか、普通にSQLを発行して実行するかで書くコードが違うのが面倒だと思っていました。また、データベースのコネクションなどは、フレームワークでうまく書かれていると、とじ忘れなどがないように考えなくてよいのですが、むしろ、コネクションなどという存在を忘れ去ってしまいたいと思っていました。

 が、しかし、これもまた大変で、コネクションプールとセットでプリコンパイルしたオブジェクトを管理し、自分で書いたコンパイラでコンパイルしたSQLから判別してプリコンパイルでやれるかどうか判断したり大変です。

 特に、この部分はコケてしまうとサーバが止まってしまうこともあるので、テストがとても大変でしたが、ソフトウェアテストの基礎知識が非常に豊かになります。

■結局、苦労するんだから最初にやってしまおう

 何事もそうですが、結局、サボろうとすると勉強するハメになります。勉強してみて分かったのですが、本当に楽をしようと思ったら基礎的なことを勉強するハメになります。

 しかし、基礎的なことはどこでも使え、一度身につけてしまえば一生ものですから、勉強や苦労の総量はかなり減るというのは確実です。

■Alinous-Coreの今後は

 Alinous-Coreは、今後もメンテナンスしていこうと考えています。本業のECサイト構築パッケージもこれで作られていますので、本業のソフトウェアの成長とともに必要な機能が付加されてどんどん良いものになってきています。

 今後の一大テーマとしては、本業で受注、出荷や顧客に関するビッグデータを扱うことがあると思いますので、メインで使っているPostgreSQL 9.2以降の機能に併走する形で並列実行などの機能を簡単に使えるようにしていこうと思っています。

 これらも、一度作ってしまえば、後々楽ができるので、どこかのタイミングで気合を入れて実装する予定です。

Comment(0)

コメント

コメントを投稿する