top / index / prev / next / target / source

2005-05-23 diary: 職業的なミドルウェア開発における哲学 , とっても不思議なStruts

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

職業的なミドルウェア開発における哲学 , とっても不思議なStruts

ミドルウェアやフレームワークと呼ばれるものを開発するときの哲学は、一般的なアプリケーションを開発する際の哲学と かなり優先順位が異なります。 , Strutsのiterateの getXXXのインディックス指定のあたりが、どうしても私はなじめません…

ミドルウェアやフレームワークといったものを開発する際の哲学

ミドルウェアやフレームワークと呼ばれるものを開発するときの哲学は、一般的なアプリケーションを開発する際の哲学と かなり異なります。少なくとも優先順位の判断基準が徹底的に異なります。特にオープンソース時代には、かなり異質な価値観が必要になってくると考えます。なお、この文章は プロ／職業における活動という前提のもとに書いています。アマチュアにおける観点、あるいは研究主体の観点からは、これとはまた全く異なる価値観となることでしょう。

納期の遵守

○○ミドルウェアとか××システムのフレームワーク作成といった際には、恐ろしいことに、一番大切なのは納期の遵守です。少なくとも、実業務をしょっている場合には、納期が非常にシビアです。特に基盤技術として提供する際には、納期が どっしりとのしかかります。もちろん、それでいてインタフェースは確定していなくてはならないのです。納期の際に誰もが納得できるようなインタフェースを提供できていることです。そしてインタフェースは確定していなくてはなりません。

納期を過ぎると、こんどは ○○ミドルウェアやＸＸフレームワークのインタフェースをターゲットとして、まだ見ぬアプリケーションが、そして想像だにしないアプリケーションが、ものすごいペースで開発され始めてしまうからです。というかインタフェースを提供できないと、ものすごいペースでの稼働ロスが発生します。(そしてすぐに金額ロスに直結します)。究極的には、納期の際に開発が可能なレベルでインタフェースを提供さへできれば良いです。そして、まだ見ぬ開発されるであろうアプリケーションと脳内リンクが成功できていなくてはなりません。そして、極論的には、内部実装の実装・改善なんてものは、後から行えばよいのです。内部実装がどんなにクズだろうが、べたべたなソースコードだろうが、インタフェースさへ変えなければ、後からじっくり検討して改善していくことは可能なのです。それが、インタフェースの提供が遅れると、ひどいことになります。3日遅れたとしましょう。ミドルウェアを開発している人間1人が3日遅れたら単に3人日の遅延です。ところが、そのインタフェース提供を待っているプログラマーが30人程度いるような現場で3日間遅延したら、なんと90人日もの損失を発生させてしまいます。1ヶ月を20日換算だとすると、4.5人月もの損失を発生してしまうのですよ！金額で考えたら、ぞっとする数字です。少なくとも、遅れを発生させたあなたが何日か徹夜したところでリカバリーできる規模ではありません。そんなことで、だいたい完成している美しいソフトウェアなんてものに価値は全く無く、今動く、内部的な(インタフェースとしては現れない範囲では)ぐだぐだでも良いから、仕様を満たして動作するようなことにこそ価値があるのです。

、、、blancoDb Enterprise Edition のソースコードがグダグダなのは、そういう理由です。(そんなところにオチが…)私が私自身が作成した箇所のある部分を見たら、やっぱりこれは 誰が見てもグダグダって箇所のソースコードがあります。汚いところは汚いし、醜いところは醜いです。まあ時間をかけて、JUnitでガチガチに固めてリファクタリングすれば改善するのでしょうけれども、今は そんなことをするヒマは無いし、実行する価値も全くありません。そんなことは重要では無くって、blancoDbが○○システムの実開発日に必要な仕様を満たすインタフェースを提供していることが大事なのです。△△システムから出た新たなる追加要望に対して、希望納期までに対応しきることが大切なのです。幸いblancoDbは典型的なバッチ処理なので、JUnitでガチガチに固めるなどしてリファクタリングするなどが容易に実現できます。また裏方ミドルウェアの多くは幸いにもJUnitで仕様を担保することが実施しやすいのです。ポイントは納期の時点でインタフェースを提供してくることができた、ということに意味があるのです。美しいコードであっても納期に間に合わなかったものには価値がないのです。というか価値が無いどころか、それ自身が悪です。納期に適切に動くことに意味があるのです。

美しくなくてはならないという宿命

しかしそれでいて、次のタイミングで訪れる納期、すなわち本番稼働など (というか、どちらかというと結合試験開始時点かも) の際には、ミドルウェアやフレームワークといったものは、設計・ソースコードが「美しく」なくてはなりません。適切に動作するために、ソースコードはシンプルで、そして美しくなくてはなりません。シンプルで美しいと、仕様変更も実施しやすくなります。シンプルであり続けるためには、機能は少なくなくてはなりません。パッケージソフトを買ってきて使うわけではないのでれば、基本的にミドルウェアやフレームワークはアジャイルと呼ばれるような手法を採用するのでしょうね？ (私は 未だにアジャイルというものをマトモに勉強したことがありません。しかし私のチームが前の世紀から ごくふつうに行ってきたプラクティスは どうやら最近アジャイルと呼ばれる手法であるようなのです。)未来に発生するような機能要件は実装してはなりません。ソースコードをシンプルで、そして低機能にとどめておかなくてはなりません。そうしないと 不慮の仕様変更に対応できなくなります。（そしてミドルウェア層には予想できないような仕様変更が ばんばん 入ってきます） JUnitでガチガチに固めたうえで、ソースコードのリファクタリングを行っていくことも良いでしょう。私は JUnitは 汚れたソースコードをきれいにするために存在する、あるいは仕様変更時にデグレードしないために存在するとすら考えます。 ※ここで前提条件になるのが、プロジェクト進行にアジャイルを引き合いに出していることから分かるように、これらミドルウェアやフレームワーク開発には少人数の一定水準以上のスキルを持った人(そして 多くの場合 ミドルウェア部分のスペシャリスト)だけでチームを構成しないといけないという点です。人を集めて組織を編成するのが、実務上はもっとも難しいところです。 ソースコードの美しさについて補足しておきます。私の美意識は、基本的に 「UNIXという考え方--その設計思想と哲学()」に近いところにあります。(…詳細に引用しようと思ったところ、探しても手元に本が見つかりませんでした…)

こてこてのGUIシステムを作るわけではない場合には、というかミドルウェア層を作成する際には、基本部分について 限りなくシンプルで、少ない行数のソースコードで、少ないファイル数で実装しておくのが良いデザイン、そして美しい設計・ソースコードであると私は考えます。加えて、仕様変更が入ったところに関して着眼して、仕様変更の入り具合にあったデザインに必要に合わせて適宜リファクタリングを行っていくと、意外にもシンプルで見通しの良い実装になります。ミドルウェア層のツールへの仕様変更は、ソフトウェア開発者の意図とはかなりかけ離れたところにおいて仕様変更として現れます。技術的に予見することが可能であったカスタマイズ性なんてものは、残念なことに ほとんどの場合全く役に立ちません。じつは、ここに重要なヒントがあります。つまり、ソフトウェア開発者は 実はシステムが見通せてい無くって、仕様変更によってはじめてシステムの本当の姿、あるべきソースコード構成などが見えてきます。そして悲しいかな、それら仕様変更は技術者泣かせなところに集中します。技術に着眼したら、あまり価値のないと考えられがちなところに、ずんどこ仕様変更は入るものなのです。それはミドルウェアの宿命であり、それを否定すると、とても使いにくい（というか使えない）システムができあがってしまいます。ミドルウェア・パッケージソフトに長いこと従事していると、だんだんこんなことが分かってくる、のだと考えます。私も、ミドルウェア・パッケージソフトに従事していた期間が 長いなぁ…。

なあんてことを、ふわりと思いました。、、、ふむ。ミドルウェアとかフレームワークの開発って、難しいですね…。

インタフェースの変更

そのように気をつけて設計・開発したとしても、やむを得ずインタフェースを変更しないといけない場面に出会ってしまう場合があります。もっともベストな対応昨策は、全開発者のソースコード・リソースをCVSに格納してもらい、バージョンタグを打ってもらいます。そして深夜または土日などの、開発者が作業を行わない時間帯に あなたがインタフェースの変更を実施するのがもっとも良い対応策です。ここであなたは、インタフェースの維持がいかに大事かを身をもって思い知ることになります。どろどろと、ソースコードを変更していくのです。実は プロ／職業的なミドルウェア開発者として、この経験を持っていることは重要なことです。対応しやすいインタフェース変更がどういうことかについても、自らの肉体を持って知ることができるからです。しかし そうはいっても残念なことに、変更後のプログラムの動作妥当性は開発担当者の方にしか検証のしようがない場面がほとんどです。(開発担当者様、ごめんなさい)インタフェースの変更の際には、コアな開発担当者にも同席してもらって (そして多くの場合は残業してもらって) 変更作業＋インタフェース変更が機能や動作に影響がない (あるいは変更箇所が適切に影響を与えていること) を検証する必要があります。

関連する日記

Seasar2が問題解決領域とする具体的に強烈な場面に遭遇！

今日 私は、私の業務上としての初めての、Seasar2に代表されるような AOPが必要な要求仕様登場の場面に直面しました。ああ、Seasar2だったら、○○で△△にしてすぐに対応できるのにっ、と強く感じました。なるほど、こういう場面には Seasar2のようなものはもってこいなのですね。

今まで、具体的な業務でAOPが必要な場面に たまたま出会わなかった (あるいは ニーズにそのような潜在的な解決策があるなんてことすら知らなかった)だけなのでしょうね。今 この目の前にあるものは、間違いなく Seasar2などが得意とする領域です。、、、少なくとも 私は自分でリフレクションなんて実装したくないですからね…。リフレクションの利用は遭遇する必要のないトラブルに高い確率で出会うための呪文ですから…

2005.05.25変更 初期バージョンでは DIやIoCと書いていましたが、私が言いたかったことは AOPのことでした。これを修正します。

とっても不思議なStruts

Strutsのiterateの getXXXのインディックス指定のあたりが、どうしても私はなじめません…。何度説明を聞いても、見ても、やはりなじめません。…私は結局 裏バッチとかミドルウェアの世界の住人で、画面系が どうしてもなじめないのでしょうね…

大阪出張

月・火と１泊２日で大阪出張です。夕飯を途中で食べに行ったら夕立に降られました。

この日記について