フレームワークのデザインで言葉が先行していることの不満。

JavaEE勉強会に参加しての想起。

製造業ではデザインが「製品の設計図」だけを指しているのではないのはよく知られている。

製造業の生産デザインであれば、動作分析やビデオ撮影法等で「人」「機械」「工具」「部品」「製品」とのインタラクションの現象を記録し、今より、いかに素早く、誤りなく、人に負荷がかからない作業ができるかの改善を考慮して、機械や部品箱などを再配置するアプローチが有名。

現象を観察し、フィードバックからよいデザインを生み出す。

私は今まで、ソフトウェア業界でフレームワークとそれの利用者のインタラクションを動作分析やビデオ撮影で記録し、フレームワーク利用者に優しいフレームワークを作りましたという話をあまり知らない。
Railsの重要概念である「DRY」「Convention over Configuration」は上記に近いものを感じるが、「言葉」が先行しているため、物足りなさを感じる。

「再利用性」「拡張容易性」「変更容易性」「テスト容易性」「DRY」「Convention over Configuration」といった「言葉」だけでよいフレームワークが生まれるの？フレームワークとその利用者のインタラクションの現象の「観察法」がないと良いフィードバクが得られず良いフレームワークは生まれないんじゃない？
という当然でありながら現状できていないという気づきでした。