ある問題を解決するために必要な工程は、突き詰めていけば、数パターンしかないと思う。
どうも、私は「その工程を突き詰めることによって本質を明らかにする」過程を楽しんでいるらしく、
その工程を必要以上に抽象化することを、むしろ避ける場合がある。
自明な工程が上から下に流れているように感じられるコードを好む。
その理由を考えてみた。
まず、
プログラムにオブジェクトを登場させて工程のあちらこちらの具体性を隠蔽する事に、
プロジェクトのメンバーが増えるとワークフローの見通しが悪くなりがちである事と同様のリスクを感じる。
また、
抽象化、模式化には、創作的自由度があり、十人十色の結果になると思っている。
「この色は自分の見ている色と違う」と感じさせたら、それは多少なりとも障壁になると思う。
なので自分の解釈を込め過ぎることにもリスクを感じる。
他にもあるかもしれないが、
とりあえず、上記 2 点に共通しているのは、
頻繁にコミュニケーションして同意を得て、
その同意事項を維持・徹底していく必要がある、という事だろうか?
しかし、
プロジェクトのメンバーが自分一人だけなら難なくクリアできそうに感じる…
…という事は要するに、メンバー間の調整がおっくうだなぁ、というだけか?
オブジェクト指向に対する抵抗感の心理的背景を自己分析できた気がするので、
今日は寝ます。
どうも、私は「その工程を突き詰めることによって本質を明らかにする」過程を楽しんでいるらしく、
その工程を必要以上に抽象化することを、むしろ避ける場合がある。
自明な工程が上から下に流れているように感じられるコードを好む。
その理由を考えてみた。
まず、
プログラムにオブジェクトを登場させて工程のあちらこちらの具体性を隠蔽する事に、
プロジェクトのメンバーが増えるとワークフローの見通しが悪くなりがちである事と同様のリスクを感じる。
また、
抽象化、模式化には、創作的自由度があり、十人十色の結果になると思っている。
「この色は自分の見ている色と違う」と感じさせたら、それは多少なりとも障壁になると思う。
なので自分の解釈を込め過ぎることにもリスクを感じる。
他にもあるかもしれないが、
とりあえず、上記 2 点に共通しているのは、
頻繁にコミュニケーションして同意を得て、
その同意事項を維持・徹底していく必要がある、という事だろうか?
しかし、
プロジェクトのメンバーが自分一人だけなら難なくクリアできそうに感じる…
…という事は要するに、メンバー間の調整がおっくうだなぁ、というだけか?
オブジェクト指向に対する抵抗感の心理的背景を自己分析できた気がするので、
今日は寝ます。
コメント (1)
Rails は絶妙だと思います。要はセンスか?うん、それも一理ある。
投稿者: master | 2007年09月15日 01:28