asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

デザインの学び方

はてなにも書いたけど、

 http://d.hatena.ne.jp/asato-d/20060617

どうやってデザインを学ぶのかに興味がある。

特に、ドメインを考慮したデザインの学び方に興味がある。

近いものとしては、Evans の「Domain Driven Design」や Fowler の「アナリシスパターン」が該当するのかもしれない。

どっちの本もまともに読んでいないけれど、少し僕の興味と異なりそうな気がする。

デザインパターン」にしろ「アジャイルソフトウェア開発の奥義」にしろ比較的にドメインに依存しない形でデザインの仕方を教えてくれる。

もちろん、ドメインに特化したデザインパターンもあると思うので、それはそれでよいと思う。


一般的にどう表現したらいいのかわからないけれど、やりたいのは比較的具体的。

今、ゲーム開発をしているので、そのゲーム開発している内容を(小さな)ドメインとして扱って、そこにおけるデザインの試行錯誤について書き留めたい。

あるいは、昔開発してたパターン認識システムがあるので、そのドメインにおけるデザインについても同じようにして書き留めたい。

問題は、どうやって書き留めるのか。パターンランゲージ形式が適切なのだろうか。

ただ、焦点は、それらのドメインにおけるデザイン上の困難な点を共有したいの ではなくデザインを学ぶ方法として、特定のドメインを扱ってみるとどうなるのか、という部分。


デザインを学ぶ方法を模索したいということかもしれない。

棋士は、定石から学ぶ。棋譜から学ぶ。実践から学ぶ。誰かに教えることで学ぶ。

では、ソフトウェアデザイナは、どうやって学ぶのか。
スポンサーサイト

Software Engineering コミュ

ソフトウェアエンジニアリングの実践者・研究者向けのコミュニティってないんだろうか。

wiki にしろ SNS みたいなのにしろ、あればよさそう。

まあ、失敗しそうなものだけど。


でも、ウィキペディアとかゲームの攻略 wiki とか、非集中的(?)に情報が蓄積されていく状況を見ていると、成功の可能性もあるのかもしれない。

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。