フレームワークのジレンマで書いた考えを実践してみる

フレームワークのジレンマ

続フレームワークのジレンマ

TO DOではなく、NOT TO DOの定義のほうが大事

競合フレームワークと比べたら負けだと思っている


つらつらとフレームワークのジレンマシリーズを書いてみましたが、思ってるだけ・考えてるだけでは
何も起こらないので実践して検証してみる。


まずはリリースプラン。どうせなら楽しくやりたいので、わかりやすく覚えやすいコードネームをつけてみた。
確定じゃないけど、晒してみる。


ver : コードネーム
0.2 : Menu : 1.0へ向けての機能の洗い出し。これ以上大きく機能は増やさない。増やす場合は、1.0以降の機能追加として配置。
0.2.3.5 : 機能のブラッシュアップ。Testの追加とJavaDocの追記。
0.2.3.6 : サブプロジェクトの分離。必要のないサブプロジェクトは削除。
0.2.3.7 : いまんところ未定
0.3 : Diet : 一旦開発ブランチへ全て保管し、機能を最小限まで削る。アーキテクチャの基本を確定させる。
0.4 : Core : HTTP/HTTPSを主としたアプリケーションの機能。エラー処理・テスト支援機能。
0.5 : Rest : REST/Ajaxを主とした機能。ちょっと一休みって意味もある。
0.6 : Star : Flex/AIRからの接続機能
0.7 : Silver : Silverlightからの接続機能

バグ修正はこのリリースプランに則らず順次行う。


肝はコードネーム「Diet」になりそう。
ポリシーとかTODO/NOT TO DOも順次晒していこうかとおもっとります。