  |
はてなキーワード: デグレとは
私の理解不足かもしれない。もうすこし詳細教えてください。
私は適切に共通化されるなら、共通化すべきだと思う。
つまり王道は共通化すること。
共通化してはいけないものを無理やり共通化してるから問題ってことですよね？
でも、実際担当者さんって、意地でも共通化しようとしてコピペで逃げればいい物を、関数を変えて、それを報告しないでデグレってあとで地雷とか
特にわからないのが、この部分。
これってどこまで共通化すべきと言うのが、
ある程度詳細設計書（指示書？）みたいなのがあるのに
勝手に変えて作ってきて問題を発生させているってことですよね。
そうすると（設計力、技術力のない）担当者が勝手に関数を変えていることが問題では？
http://anond.hatelabo.jp/20091010201820
たとえば、高度な数学を使った暗号化モジュールなどは共通化しておかないと、新人プログラマーにまかせても無理。
printfを大量に書くたぐいの、物は書いたとおり勉強になるからという理由で任せることもある。
本当に水物。
そもそも仕様上 共通化になるとおもっていても、仕様変更が途中で入って、ならななかったので、別関数に分ける等のことは良くあること。
なので、設計から共通化部を割り出すことに意味がないとはいわないし、役立つこともあるだろうけど 王道だと思っていると痛い目を見ると言うこと。
（痛い目を見たので共通化はほどほどにという事。）
なので、本当にメンバーのチーム力や、納期、どのぐらい勉強させるか？難易度は？などによって、全部違う。
実際に設計を担当する人間からすれば、任せるプログラマーの力量に応じて作業分担するのも責任。というはなしで、視点はＳＥ視点。
時には同じそうに見えるけど２つ作っておくことも悪くないという事。
プログラマー視点ではみてないので。
http://anond.hatelabo.jp/20091010210506
仕様から共通化しておくことも悪くないけど、結局、やってみたら、何かの理由で共通化できなかった。とかあって。
大プロジェクトだと目が届かなくて、変な共通化をされていて、無駄に遅いとか、無駄に重いとか、変にスパゲティとっか変なことになってることがある。
別に、仕様から共通化しておくことが悪いとは言ってないよ。
コピペで逃げられるなら、それでもいいしね。
でも、実際担当者さんって、意地でも共通化しようとしてコピペで逃げればいい物を、関数を変えて、それを報告しないでデグレってあとで地雷とか
起きるからね・・・。
プログラマさんには過度の共通化はやめて、コピペするときはコピペしろって言っておかないと。
プログラム的にはこれで美しいんです！！って言われて、あとで、デグレ試験が大変みたいなそういう話し。
繰り返しになるけど、王道がないって事が言いたいだけで、技術的分け方が王道って言っていない。それすらも王道じゃないって話しで付けておいた。
結論から言うと、
月産1000行/人×１０でも
月産5000-10000行/人×３でも
そんなもんどっちでもいいのヨ。
そのうちの一人が
「まともにプログラミング初めてｘｘ年の俺ですら、設計しながら月産ｘｘ行は書けるぞ。」って言い出して、
一人でナニゴトかやりはじめさえしなければ。
人数が多すぎようが、それ（人・仕様・全体スケジュール）をとりまとめるポジションが明確で、
スタンドプレイで後はシラネ、って奴がいなければ
少なくともデグレだの、開発総入れ替えだのって話はぐんと減る。
だから、プログラマなんて「どうでもいい」んだよ。
お隣とお話して全てが解決するような規模のシステムなら、単純に人数が少なければ少ないほどいいけどネ。
ま、あと、馬鹿正直に人月計算だけで請け負うなんてアホな見積もりはありえな…
ってデジャヴを感じるんだが気のせいか。
まーそういう業界的なことはどうでもいいんだけどさ。
業界内の人間がそう思っちゃうと、元増田みたいなデグレスパイラルが待ってるノヨ
「誰が何をできるか」が問題じゃなく、
「誰が何をするか」が問題なんだよね。
「プログラマなんだろ？直せるんだろ？」
「俺は設計もコーディングもできるからやれますよ！（でも元設計なんて人がやった物シラネ）」
って事やってるから、改修するたびにバグ起こすのさ。
デグレはやるべき事をやらないで「やってしまった」場合に起こるんだから
そこ重要。
1. はありえない。本当にPGなら。
ただし、バグがあると分かっていてリリースするアホはこれまたありえない
正解は「プログラマーはバグがあると分かっていて、バグも内密に積み上げられているが、リーダーはバグがないと”信じている”とコメントする」じゃないのかな？
2. ３０個どころではない気もするが…小規模ならそんなモン？
単体で確率的に1/5。総合で更に2/5程度で掛け算するといい感じかも
3. １０個のバグを修正し、
１０個は仕様だと答え、
１０個は再現しないと付き返す
残りの１０個は何が悪いのか判断もできず
…キリの悪い数字だな
4. 割合的にデグレ＋デバックで浮上するバグはこんなモンかなー。
5. デバック：テスト１回あたりのスパンが週とか１ヶ月程度だと繰り返す。
（３，４回どころですめばマシ）
数ヶ月スパンになれば繰り返しはその分減る。
6. 善人がリーダーであれば、バグがある上でのリリースだと伝えられるが、
１：の考えを持ったリーダーが上にいた場合は、バグは隠蔽されたままリリースされる
7.半分くらいかなぁ。ただし、ユーザが思う「バグ」は本来のバグじゃない（いわゆる要望）ことも含める
8. プログラマくらいなら転職はどーでもいい。SEレベルだと問題。
9. そしてその開発チームはバグを発生させた責任は、当初の開発に押し付ける。そして資金が切れる。
鬱になるのは開発と、バグだらけのシステムをリリースされた現場担当者。
真剣に「プログラマ」が問題って考えてるなら、そもそもシステム開発なんざするな
12. コードを書き始めるのがそもそも間違い。
うちはこんなもんかなー。
