■http://anond.hatelabo.jp/20091010221434

適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切？というのがあるから。

速度に対して最適化するのか、メモリーにたいして最適化するのか、費用に対して最適化するのか、期間に対して最適化するのか？

適切が意味する要素がプロジェクト毎に違う。

なので、適切に共通化　という単語が成立しにくい。ある条件下ではAという共通化が最適でも、違う条件下ではBという共通化が最適だったりする。

そんで、プロジェクト１年目の受注では条件Aだったが、翌年の追加案件ではBだった。みたいなことが起こりえる。他にも色々。

そんで、重要なのは、この辺というのは、人によって解釈が違うし、主義もあるし、宗派もあるってこと。

規律だ設計だ、ルールだを持ち出しても良いけど、現実問題として、人を理由とした摩擦や問題は起きるという事。

そういう事例に対して、設計は正しいのにみんながルールを守らないから、とか言い出してもしょうがなくて、

リーダーに求められるのはプロジェクトを成功させることであって、モジュールを共通化させることではない。という事。

前者は目的であって、後者は手段。

よって、目的達成のために、最適な手段をとる。という意味では、共通化という命題は、技術的にはすばらしいが政治的にすばらしくないことがあるので、

趣味ではなく業務としてのプログラムでは、優先課題ではない。という事。

で、結局、どうするかと言われれば、今いるメンバーで、出来る範囲で、次のプロジェクトが来ても、問題ない程度で設計するって話しになる。

ぶっちゃけたところ、共通化の話題は、結構、オブジェクト指向だ、やれなんだで、宗教論争になりがちで、理想を追い求めガチだから、ほどほどにしろ、って口をすっぱくしていわないと、

共通化のための共通化になって、全体を阻害することがあるから、マネージングする側としては要注意だと。

イヤ本当に、正直、理想を追い求めた、高度すぎる抽象化はいらん。結局、ながくプロジェクトを続けられるコツは、次がどうなるか何てわからないんだから、共通化は『ほどほど』にしておく。ってところに落ち着く。

で、技術的に高度なところだけは、信頼できる人にやって貰うか、自分でヤルって話しに落ち着く。そこ以外は、なんつーか、もう、ほんと、手工業だからねぇ、この業界。って話し。

なんというか、適当な設計だなぁって言われることもあるだろうけど、そういう風に、各個人毎に機能を割り振って、最低限の所だけ押さえるのも設計と思うわけですよ。

一人でやってるなら、共通化しちゃっても良いことも、複数人でやってると分けた方がよいこともある。その辺のさじ加減が設計。ほんと、人依存。

Permalink | 記事への反応(1) | 22:39

ツイートシェア