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

Java


反響どうもありがとうございます。
まとめてになっちゃうのですが、面白い議論なのでいくつかレスして引っ張ります＾＾；

あと、ユーザーの性質による部分もあると思います。
最適なものを作りたいなら１から作るべきですし、それだと時間が足りない場合は
スクラッチで作ったりしますし。スクラッチ（スクラッチ部分のテストが発生）するのがめんどくさいかつ、
最適でなくて問題ないシステムであるならばフルスペック（スクラッチがないため連携テストの必要がない）のフレームワーク
もって来たりしますし。

http://d.hatena.ne.jp/shot6/20080627#c1214581000

なるほど。
私のコンテキストの問題もあるのですが、私が言っているフレームワークとはたぶんに
Webフレームワーク、特にプレゼンテーション部分に特化していることが多いと思ってもらってよいです。
（自分の性質上そうなってそうなので。）

これはTomatoさんが言う、

Eclipse等の様に汎用性が求められるものと、Webフレームワークの様な比較的小さな「とんがった思考」により作られるものでは、
埋めることのできない違いがあると思います。

とほぼ同じ意見ですね。自分の語る言葉の背景がWebフレームワーク前提という点で。


なので、ユーザの性質というのもあるかと思いますが、私の場合は領域に偏りがある前提です。
つまりプレゼンテーション層のフレームワーク、という前提があった上で、厳選されたミニマルセットと
それを補うような機能の開発は分離すべきじゃないかなあという考えにいたりました。



また、引き続きid:kensir0uさんが言っている下記のような点にも同意できます。

かなり難しいのですが求められている重要なポイントを汲み取りその機能が最高レベルであればユーザーも増え、
おのずと必要な追加機能は他者、有志でつくられていくと思います。で、追加機能がある程度標準的に使われだしたら
そのうちコアに取り込むというスタンスでいいんじゃないかなと思います。

http://d.hatena.ne.jp/shot6/20080627#c1214581000


理想はそのとおりですね。
これがうまくいっているOSSは長期間にわたって、繁栄しているんじゃないかなと。
自分が作るOSSもそうありたいなと常々思ってます。
ただしそのためにはコアを提供するチームには厳選する目というのが必要じゃないかと思うわけです。
まだまだ未熟モンなんですが、ようやくそれに気づいたというか気づけたというところなんです。


よく例えに出てきますが、iPodをはじめとするAppleの製品はSteve Jobsの1000のNOをうけて
ようやく製品が出荷されるところにたどり着きます。そういう厳しい目で機能追加の誘惑に勝っていかないと
結果として製品自体の魅力を損ねてしまうのではないかと、今は思っています。
（もちろんSteve Jobsになれるわけでもなければ、そうなりたいわけでもないです。が姿勢は見習うべきでしょう。）



また、仕様と実装の分離という点でid:shinさんからblogでコメントいただきました。
いつもありがとうございます＾＾

長期的なことを考えるのならば，仕様はドキュメントでしっかりと用意したほうがいいですね．
パッチをすぐにあてていくのはいいのですが，どうしても今実装されている内容が仕様という感じになりがちです．
仕様と実装を分離して考えたほうがいい．JavaEE仕様とかそんな感じで．したがって仕様外の使い方は実装依存である，と．
そうすると他の技術者からのパッチなどフィードバックも集まりやすいのではないでしょうか？

http://d.hatena.ne.jp/shin/20080627/p2


どの挙動が正しいのかという点で極小ではあるものの、仕様というのは明確にしたほうがいいですね。
なかなか全部を示しきるのは難しいと思いますが、そもそもの意図・ポリシー、そしてそれを受けての仕様は
ある程度示すべきかなあと考えます。実装が先かなあと思いますが、仕様は明記すべきという意見に賛成です。


また仕様と実装の進め方についても意見いただいてます。

最初の取っ掛かりはものが出来上がってくれないと困るので実装最優先は仕方がないと思います．
そこから仕様を取り出すほうが現実的ですね．

実装コードを書いた後でインターフェースを取り出すというか．

でも安定して運用するフェーズにはいってからは仕様を確定するほうを優先したほうがいいと思います．

http://d.hatena.ne.jp/shin/20080628/p2#c1214644348

実装最優先と仕様確定の切り替えが結構肝ですね。
わかりやすいのは1.0以前は実装最優先てことになるのですが、それだと使ってもらうには
あまりに長くかかりすぎるのでもう少し細かく仕様確定していきたいと思ってます。


次にUNIXの思想との関連について書いていただいた、id:smegheadさんの意見にレスします。
この意見はとても的を得てますね。

多機能なフレームワークに関わってきたshot6さんが、「削る」という考え方に、シフトしているのを興味深く読ませてもらいました。

ある意味では、UNIX的な考え方に近づいているんじゃないでしょうか。

http://d.hatena.ne.jp/smeghead/20080628/unix

UNIXの「Small is beautiful」という考え方は私の大好きな考え方の一つです。
まだネットワーク運用とかそういう仕事をしているときに、下記の本「UNIXという考え方―その設計思想と哲学」を
よく読みました。今でもこの本は自分の中で原点というべき本の一つです。


今まではこの本で言われている事と今の自分の仕事やOSSが今ひとつリンクしていなかったのですが、
ようやく少しだけリンクしてきたから、やっと今になってOSS開発に活かせるかもと思っているのかもしれません。




UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学




最後に軽くまとめてみます。
フレームワークのジレンマを読んでくれた方々も機能を厳選するという点には結構同意してもらえたんじゃないかなと
思っています。
ただしその後の機能追加に関しては様々なやり方があるので、一概にいえないですが
コア部分を実装し確定させたら仕様を明記することで、まわりからの理解や貢献なども得やすい状況を作っていくことが、
ユーザさんだけでなく自分達にとってもより良い状況なんじゃないかなと考えています。


こういうコアを作った人達とまわりの状況がより良いモノを生み出すサイクルを「Harvested」（果実などの収穫って意味）な状況とでも言ってみますか。
（もしかしたら高井さんがどんびきで触れてたかもしれないけど。）
OSSといわず製品開発ではこのようなHarvestedな状況が誰にとっても望ましいんじゃないかと自分は考えます。



今作っているWebフレームワークは、上にあげたような点を基本的な考え方に取り込んで試行錯誤してみたいなと思ってます。