ようやっと、３ヶ月の戦いの日々が落ち着いてきて、 SAStruts、そして Servlet と格闘し続けてきて、 めっちゃSAStruts拡張(ラップ!?)して... 現場のプログラマーからは、 「もうSAStruts使ってる気がしないですな」 「これ以外のSAStruts環境で実装したくないですよ」 「めっちゃ業務に集中できた」 という最高の賛辞を頂きまして、 ああ、(無理しても)やってよかったなぁと。 こういった言葉を頂けることが、 jfluteにとっては最大の喜びです。 ちょっとだけ緊張が解けた状態、ふぅ。 もちろん、その現場、その組織、そのビジネス、 これらにフィットした最適なものということで、 必ずしもどの環境でも最高のもの、 ってわけじゃないですけどね。 (アーキテクチャは要件があって初めて語れる) とにもかくにもなによりも、 ディベロッパーのスピードを 最大限高めることができたんじゃないかと！ リーン・スタートアップを支えることができた。 勝手ながら思っています。 そう、今回は DBFlute のみならず、 WEB周りの仕組みでがっつり貢献できたかなと。 「安全はスピード」というテーマは共通です。 -> DB変更に強い、という古風な特技 | jfluteの日記 SAStrutsの拡張研究という感じで、 プライベートな時間に作ってそれを業務に 適用したって感じのものもあるので、 (にわとりとたまごの関係ですけどね..) そのうち一部は皆さんに紹介する機会があるかも。 スモールな勉強会を継続的にやっていきたいので、 そこでお話することもあるかもしれませんね。 RoutingFilter, RequestProcessor, ActionWrapper, FormTag, CustomizerChain...
SAStrutsはよくできたフレームワークである、 ということはいまさら言う必要もないでしょう。 それは逆に、この変化の激しいWEB周り、 もっとリッチで高機能なフレームワークが なかなか生き続けるのが難しいことを、 暗に示してるとも言えるかなと。 その変化に対応し続けなければならない。 それはかなりしんどいことだと思います。 SAStrutsは、Strutsの薄いラッパー、 変化の激しい部分に突っ込み過ぎず、 そこは現場(利用者)に埋めてもらう。 そう、なので機能は足らないのです。 しっかり開発やろうとすると、 ある程度の拡張は覚悟しておかないと。 拡張というか別にオーバーライドせずとも、 自前でServletFilterやInterceptorなどを 駆使して補っていかなければならない。 どのSAStrutsの現場を見てもそうなってますね。 フレームワークってほどおおげさでなくても、 でもやってることは要は「自前の仕組み」です。 そこがめちゃめちゃバラけまくってるので、 「SAStrutsを使ってる現場」に行っても、 SAStrutsの知識だけではやっていけない。 もちろん、どんなフレームワーク使おうとも、 業務(現場)と汎用的なフレームワークの溝を 埋める作業は必要です。それこそが現場フィット。 ただ、単純に「程度」の問題ですね。 SAStruts(というかStrutsも)は、 その埋めるコストがそれなりに覚悟が必要です。 それは単に溝が大きいというのもありますが、 その溝を埋めることに対するSAStrutsの親和性も そんな高くないって感じるところも!? オーバーライドしづらい、とかたくさんあって。 WEBフレームワークは、いつも周りの人と 「しっかりしたもの作ってしまいたいね」 っていう話にはなるのですが、 それにはかなり体力と機会損失の覚悟が必要。
でもまあ、今回作ったのは、 業務に依存させずに別のプロジェクトで すんなり再利用できるように作りました。 なんというか、溝は完全に埋めてはいないです。 SAStrutsと現場(業務)の溝を「ある程度」埋めて、 残りの溝をそれぞれのプロジェクトで独自に 埋めるための拡張ポイントをあらかじめ用意して、 わりかし低コストで現場フィットできるような 仕組みを意識してみました。 その現場のその組織では、 もう SAStruts に悩むことは、 うーん...まあもうあんまりないはずかと（＾＾ (Servlet, 特にtaglibには悩むだろうけど) 実はこの「依存性の排除」が大変なことで、 大抵は「汎用的なものを作ろう」って言って、 途中からどんどんプロジェクト依存してきて、 すんなり移行できないものになるから。 これが社内フレームワークが失敗するときの 典型的なパターンかと。 そのためには...時間!? いやいや、 丁寧に実装する時間なんてない。 フレームワーク作りに工数をどっぷり 割り当てられるプロジェクトなんてめったない。 そう、フレームワーク作りながら開発も進める。 二つのことを意識しました。 A. 最初から綺麗に作ろうとしない B. フレームワーク変更に強い仕組み
A. 最初から綺麗に作ろうとしない まずは必要になった機能を真っ先に提供して、 プログラマーが作業が進められることが大前提。 プログラマーの作業は絶対に止めてはいけない。 (そこがクリティカルパスになると本末転倒) プログラミングのリズムは以前のブログの通り。 // リファクタリングは思考のツール http://d.hatena.ne.jp/jflute/20121202/1354442627 最初から綺麗に作るプログラミングは... 通用しない、と言いたいところですが、 まあもう少し柔らかく言うと、 「あまり」通用しない。 プログラマーの作業は止めちゃいけないのだから。 要はプログラミングのアクセルの踏み加減の柔軟性が 求められるってところで、踏むときは踏む。 でも、ボロボロでも提供するときは提供する。 そこで要件をすぐにキャッチできなきゃ、 もうそこは画面ごとにベタベタ書かれて、 フレームワークによる管理が行き届かなくなるから。 そのボロボロさ加減をしっかり把握しておいて、 後で隙あらばすぐにカバーできるようにしておく、 ってことの方が大切。 実は、DBFlute...というか、 オープンソースの開発と似てるのです。 キャッチが遅れたら、機能ユーザーが減るのです。
B. フレームワーク変更に強い仕組み 「DB変更しながら開発していくからDBFluteで」 って話と同じように、フレームワークの修正・変更に 強いアーキテクチャというかインターフェースを 提供していかないといけない。 "A" のためにも、ってところですね。 フレームワークを微調整しながら進むわけですが、 その影響による手戻りでディベロッパーの作業を 止めてはいけない。(これは必須！) 「影響があるにしても、 影響範囲を特定しやすいように」 であれば、自分で直せちゃうので。 って簡単なことじゃないですが、 プログラミングしながら、できるだけ意識。 この辺は、コンパイルセーフ言語じゃないと なかなかできなかっただろうなぁと感じるところ。 わかりやすいところでは、 フレームワークネイティブなクラスは あまりさらさない、diconコピーはさせない、 などなど色々気を使いましたね。
とは言ってもですねっ、 理想(方法論)ばかりじゃ現実にならないので、 そりゃぁ、大晦日も正月も実装しまくりました。 (両方のアプローチが必要) 来週に必要になる機能を土日に作り上げて、 月曜日からディベロッパーに使ってもらう。 色々かっこいいこと書いちゃってますが、 ボロボロでもまずは実装できるもの出して、 土日に必死に綺麗に作り直したりってことも... と思ったら、日曜も作業してるじゃーん！ という感じで "A" の繰り返しです。 (正月!? 大晦日!? だっけかな、コンフリクトした...) でも、やってやろうという意気込みでした。 完全にスクラッチの開発ということで、 こんなチャンスはめったにない。 なんせ今まで、色々と「既存の仕組みが...」 というしがらみで泣くことが多かったから、 プライベートなんかつぶして当たり前だと。 (余暇プログラミングはしてたけどっ) 大変でしたが、楽しかったですね。 冒険しながらプログラミングしてる感じ。 状況状況でアクセル踏んだりブレーキかけたり、 急激にハンドル回したりってレースしてるみたい。 そう、これも冒険プログラミングだ！ -> DBFluteの冒険プログラミング まあ、テンションやリズムは色々と変われど、 リリース後も似たような感じで続くでしょう。 現場は生き物のように変わっていくから、 それに合わせてアクセルの踏み加減を調整して、 実装サービスを提供していく。 これが jflute の仕事。 そして、 その仕組みとDBFluteを使いこなしてくれた、 ディベロッパーのみんなに深い感謝、ありがとう！
