どんな視点でのless is moreか
Seasar2の後継はSlim, Seasar Less Is Moreだそうです。
この標語はS2JDBCとかSAStrutsでも確か？聞いたような気がします。
＃ちょっと「かんたん携帯」みたいなものを連想しました。
それはさておき、表題のとおり、どんな視点でのless is moreか？というのがひとつの疑問です。
眠い中で書いたメモなので支離滅裂ですが・・・追記：朝ちょっとだけ整理
- インピーダンスミスマッチのようなものを、マニアックなケースまで全てラップしたりすると、複雑になりがち→割り切り(S2JDBC)
- S2Struts→Teeda→SAStrutsの流れの中で、レイヤごとにクラスを分ける考え方は薄くなってきている(S2Strutsのときはpage-action-service-dao,Teedaはpage[-service]-dao, SAStrutsはaction[-service]-dao*1 )
- 新規開発の場合と、派生開発(仕様変更、障害対応)の場合で求められるものは、似ているんだけど多分完全には同じじゃなさそうです。
- 昔のCASEツールのコード自動生成は、新規はいいがその後の保守性が悪い
- 記述量の問題か、知識量の問題か
- S2Struts,SAStrutsでは結局StrutsやJSP(or mayaa)を必ず意識する。Teedaは一見JSFを知らなくてもよさそうだけど、米林さんの講演によると、JSFでの開発経験相当の知識が必要。→記述量がless ≠ 必要な知識がless
- でも、フレームワークが薄ければ、覚えることが少なくなるのは確か。もし、フレームワークが手厚いケアをすることによって、アプリの記述量がlessになっているとすると、そのフレームワークやその背景知識はmore必要そう。
- DRY原則などで、二度同じことを書かない、ということは、裏を返せば、一度は書く必要がある、という意味。書く必要があるものは、書く必要がある。(トートロジー) では、その書く必要があるものとはなんなのか
- なぜServletを裸で扱わないで、Strutsというものが開発されたのか。
- いらないものをそぎおとしたら、ワークフローエンジン
↑いろいろまとまりなく浮かんだことを書いただけなので、終了^^;
