日記/2007/10/16/YakiBikiの基本方針メモ

随分久しぶりに・・・。この間、Xhwlayをやっていたから。4ヶ月ぶり。

とりあえず、基本方針だけメモ。

とにかく捨てる。

言葉が悪いようであれば、「実装しないでおく」。或いは「考えないでおく」。ようするに「後回し」。

非常に難しいのだけれど、とにかく、鳥羽口を開く為の0.0.1を作る為には、これを徹底するほか無い。

クラス設計の美しさを捨てる。

クラス設計を必要以上に捻る必要は現段階では無用。どうせ変わるんだし。

DBの便利さを捨てる。

スキーマ考えるのが面倒。UnitTest用にデータをとっかえひっかえが面倒。

gettextを捨てる。

代替物を調整するのは後回しでよい。文句を付けられるのは、動く物が出来上がってから。文句付けるくらいならcommitしろや(#ﾟДﾟ)ｺﾞﾙｧ!!・・・じゃないけれども。っつーか開発はWindows上だし。

PEAR_Authを捨てる。

とにかく、デモれるだけのユーザー管理機能があればいい。んなエンタープライズ的な機能は後回し。

速度を捨てる。

遅くなってから考えろ。とりあえずCache_Liteでどうにかなるだろ。

捨てられない物。

これだけは捨てられない。

インデントはスペース4つ分。 →趣味。

80桁改行。 →趣味。

テスト駆動開発。 →クラスを作るときの、外部I/Fの「スケッチ」としての効果がある。厳密なエラー系まではまだ考慮せず、「こんな感じでこのクラスは動くだろう～。」を描く効果があるので、採用する。

とにかく捨てる。

0.0.1が動けば、あとはどうにかなる。状況を、動かす事ができる筈。

2008年12月時点での感想

なんだかんだ言っておきながら、結構捨てられないモノもありました。

• gettextを捨てる。
  • 見栄で英語・日本語のtranslationを実装する為、結局自前のtranslation機能を作ってしまいました。
  • 悩んだ・・・記憶があるのですが、translation周りって「後で実装」が非常に面倒くさい部分だったので、最初から作り込んでおいた方が良いと判断した次第です。
• 速度を捨てる。
  • 結局Cache_LiteやSingletonまがいの作りで、同じデータファイルを複数回読んだりするのを避ける為にいろいろしてしまいました。
  • ぶっちゃけ一ページ表示するためにはそんなに、同じDAOを何度もアクセスするような処理は発生しないので、この点はオーバースペックだったと思います。
  • 特にSingletonやCache周りは、テストケースを全て動作させる時に嵌ってしまいまして、相当苦しめられたｔころです。正直今でも、「ここのCacheは要らないだろう・・・」と思うところも何箇所か有ります。
    • find系のcacheは要らないだろう。

とにかく2007年の10月 - 12月はかなりアレコレ悩んだ事は確かです。大凡の仕様は頭にありましたが、詳細を詰めていったりACLとの連携を考えたり、実際にクラスや作りに落とし込む時の方針など、いくら悩んでも悩み足りないという感じでした。
こういう時、やはり相談できる人がいたら、もう少しスピードも上がっていたと思います。なまじ一人で考え込んでしまうと、「ほどほどでこの辺で落とし込んでおけばいいだろう」というブレーキが働かず、結構疲れました。