■

その辺のバランス取りが設計力。設計力に、こうなるみたいな王道はなくて、チームメンバー他　状況次第の水物。

http://anond.hatelabo.jp/20091010201820

たとえば、高度な数学を使った暗号化モジュールなどは共通化しておかないと、新人プログラマーにまかせても無理。

printfを大量に書くたぐいの、物は書いたとおり勉強になるからという理由で任せることもある。

本当に水物。

そもそも仕様上　共通化になるとおもっていても、仕様変更が途中で入って、ならななかったので、別関数に分ける等のことは良くあること。

なので、設計から共通化部を割り出すことに意味がないとはいわないし、役立つこともあるだろうけど　王道だと思っていると痛い目を見ると言うこと。

（痛い目を見たので共通化はほどほどにという事。）

なので、本当にメンバーのチーム力や、納期、どのぐらい勉強させるか？難易度は？などによって、全部違う。

実際に設計を担当する人間からすれば、任せるプログラマーの力量に応じて作業分担するのも責任。というはなしで、視点はＳＥ視点。

時には同じそうに見えるけど２つ作っておくことも悪くないという事。

プログラマー視点ではみてないので。

http://anond.hatelabo.jp/20091010210506

仕様から共通化しておくことも悪くないけど、結局、やってみたら、何かの理由で共通化できなかった。とかあって。

大プロジェクトだと目が届かなくて、変な共通化をされていて、無駄に遅いとか、無駄に重いとか、変にスパゲティとっか変なことになってることがある。

理想と現実の違いだと。

別に、仕様から共通化しておくことが悪いとは言ってないよ。

コピペで逃げられるなら、それでもいいしね。

でも、実際担当者さんって、意地でも共通化しようとしてコピペで逃げればいい物を、関数を変えて、それを報告しないでデグレってあとで地雷とか

起きるからね・・・。

プログラマさんには過度の共通化はやめて、コピペするときはコピペしろって言っておかないと。

プログラム的にはこれで美しいんです！！って言われて、あとで、デグレ試験が大変みたいなそういう話し。

繰り返しになるけど、王道がないって事が言いたいだけで、技術的分け方が王道って言っていない。それすらも王道じゃないって話しで付けておいた。

Permalink | 記事への反応(2) | 21:21

ツイートシェア