  |
適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切？というのがあるから。
適切の基準が曖昧でプロジェクトによってことなるのもその通りです。
エンジニア的には正しくても、会社的に正しくないことがあり元増田のおっしゃる通りだと思います。
王道が共通化というのは訂正します。
ただエンジニア的には共通化は正しく、
エンジニア上がり人は取り締まりに役になってもこんな事言ってたりします。
http://d.hatena.ne.jp/iad_otomamay/20090413/1239632703
内部設計の段階で、内部設計書書いて(or担当者に書かせて)してはどうでしょうか？
そして、そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間と
レビュー実施するようにすべきだと思います。
実装されているか(共通化を含む)項目つくるものだと思うのですが、
内部設計書は作ってないのですか？
担当者のせいばかりにしていても解決しない問題と思っています。
逆 ２０機能で同一関数を使っているとその同一関数を１行修正すると２０機能全部デグレード試験し直し。 逆に２０機能を２０関数で使っていると、１つの関数を直しても１９機能の...
・機能の共通化は必ずしも、トータルでの工数を減らしたりはしない。どころか、増やしたりもする。 ・共通化する関数に求められる品質依存。その関数に求められるクオリティー...
その辺のバランス取りが設計力。設計力に、こうなるみたいな王道はなくて、チームメンバー他 状況次第の水物。 http://anond.hatelabo.jp/20091010201820 たとえば、高度な数学を使った暗号化...
私の理解不足かもしれない。もうすこし詳細教えてください。 私は適切に共通化されるなら、共通化すべきだと思う。 つまり王道は共通化すること。 共通化がわるいというよりは、設...
適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切？というのがあるから。 速度に対して最適化するのか、メモリーにたいして最適化するのか、費用に対...
適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切？というのがあるから。 また適切の基準が曖昧でプロジェクトによってことなるのもその通りでうｓ...
元増田って http://anond.hatelabo.jp/20091010180917 でいいですよね？ 違ったら以下は無視してね。 内部設計書は書いてますよ。 でも元エントリーで私が言及してるのは システムテストの工数...
IDとかコテハンの内増田では議論しにくいですねorz 多分http://anond.hatelabo.jp/20091010232609 でいいている元増田はあなたです。 システムテストに関してはhttp://anond.hatelabo.jp/20091010210506 で書い...
自分自身がエンジニアで共通化を推し進めるべきだとずっとやってきたけど、 その結論として、共通化しない方が良い場合も多いという反省が残ったって事だから。 結局、その見切りが...
引き継ぎとかも考えると、コピペコードの方が引き継ぎが楽な場合も多いんだわ。これが。 それは、貴方の体験ではそうだったかもしれないけれど、 私の体験では逆だなぁ。 た...
一応、誤解のないようにいっておくとあなたの責任を追及しているわけではありません。 エンジニア的には共通化することは正しくても、 システム変更の工数とか会社営業的な視点とか...
実際に設計を担当する人間からすれば、任せるプログラマーの力量に応じて作業分担するのも責任。というはなし 時には同じそうに見えるけど２つ作っておくことも悪くないという...
逆 ２０機能で同一関数を使っているとその同一関数を１行修正すると２０機能全部デグレード試験し直し。 逆に２０機能を２０関数で使っていると、１つの関数を直しても１９機能...
ちょっと追記。 共通関数をコピペして＆修正した場合もコピー先全パス試験しろという職場にはこの方法は向かないですね。 (多分、対官公庁、対銀行の仕事してる人は全パス試験しろ...
5
