そろそろフレームワーク

個人的な目標として、『5月頃には単純なフレームワークを作れるようになりたい』ってな事を考えてた。

まあ、フレームワークと言えるような物じゃないけど、アプリケーション(バッチ処理)の基盤はなんとなくで作ってたりした。『フレームワークを作ろう!』って意気込んでた訳じゃなくて、単純に本とか読んだ受け売りのまま『共通っぽい事は上に書き出そう』って流れでそうなっただけの事。

実は、仕事で既存アプリ(自社サービス)のフレームワーク整理(リファクタリング)をする事になって、その担当になってたりする。ゼロから作る訳じゃないし、さほど汎用性も求められてないと思うのでなんとかなるかな、と。ただ、『普通』ってものがよくわからないので、Symfony とか Ethna とか Maple とかっていうのを読んでみないといけないなとは思う。仕組みというか流儀を知りたいだけだから Rails でもいいんだけど。

まずやらなきゃいけない事は、『何が要求されてるか』の整理。そもそも、既存フレームワークを使うかどうかって判断が必要かも微妙だけど、要求されてる事が Symfony とかで賄えるならそれでもいいかな、と。ただ、デプロイツールとかバージョン管理とかの、現行の運用に支障を来しそうな点には注意。いじくる範囲も、ページ処理とかフォーム処理って言う部分だし、何より『他のサービスでも使う予定』ってのがまだはっきりしてなかったり。

プロジェクト内のタスクとして『フレームワーク部分を整理する』みたいな物を持つか、ラボ企画っぽく別枠で『自社フレームワーク開発』プロジェクトを立ち上げるかも考えないとかも。正直、リファクタリングの範囲を超えてる気がしてて、いっそじっくりと基盤固めをすべきかなとも思う。

多分、アプリケーション別にオリジナルフレームワークを持つ事の利点は『柔軟性』なんだと思う。既存フレームワークを使うと、楽できて嬉しいけど『枠』っていう限界があるのかもしれない。『規約重要』って事を考えると、むしろ『枠にはめる』事こそ重要なのかもだけど。

今、大まかに2種類のサービスを運用していく方針があって、その種類ごとに子サービスを立ち上げていくような気配。なので、それぞれで見通せる分だけに対応したフレームワークをちょっとずつ作っていくのでもいいのかもしれない。ただ、そうするとチーム間に変な溝が出来そう。フレームワークは基盤な訳だから、会社で1個ってのが理想だと思う。言語を複数使うのは別にいいと思うし、それが理由でフレームワークが複数あるってのもいいと思う。勿論、言語別フレームワークも理念は一緒であるべきだと思うし、言語内でのフレームワークは1本化した方が動きやすいと思う。アプリケーション別にベストプラクティスってのがあるのかもしれないけど。できる技術者はフレームワークの違いとか気にならない物なのかな?

今抱えてるタスクがちょっと上手くいってない上に、性質上神経質にならざるを得ない部分だからちょっととんがり気味。さらに、ちょっとした業務上の変更もあったり、自分の役割がちょこっと変わりそうな気配もあるだけに、『オレに触るとやけどするぜ』状態だったり。全部自分にプラスになる事だから、喜ぶべき事なんだけど軽くテンパリ。まあ、そんな中でも問答無用で定時で帰ってるんだけどね。

  • 役割変わりそうですけど、本当のところどうなんですか?
  • 今のタスク明日いったら上手くいってください
  • フレームワークについてはしばらく忘れます

頭を整理して、多分こんな状況。一番上はすぐに確認しなきゃいけないところなんだけど、どうも今のタスクのせいで余裕がなくなってる。フレームワークはまあ、まずはタスクを消化してから考えるようにしないと。頭に入った事を片っ端からやろうとしてもパンクするだけだし。

フレームワークに関しては、Rails 使ってる人が(多分)2人もいる訳だし、煮詰まっても要点整理して聞きにいったらきっと解決するはず!(と、ここで軽いプレッシャーをかけときましょう)

そんなこんなで、とげとげした1週間を送ってみます。


チャンピオンズリーグどうしよう…。AM03:35 か。

プロフィール

このブログ記事について

このページは、koshigoeが2006年5月17日 22:35に書いたブログ記事です。

ひとつ前のブログ記事は「Google Notebook とてもよい」です。

次のブログ記事は「バルサ!!!」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。