＞ダメだと思ったら、せっかく作ったものでも、捨てる勇気を。
関数単位とか、モジュール単位とかの話ね。

管理の手法は、ほかにいろいろ意見あるからそっちに譲るとして、
結合試験のようなユニットテストが終わった（はずの）状態で
沢山バグレポートが上がってくることは、よくあることですけど、
バグレポートの中から、「どこが腐ってるか」を見極めて、
（デバッグと平行して、でしょうけど）そこを思いきって書きなおす
事も収束させるのに重要なんではないかと。

それから、バグレポートは、

　　　　記入者　　　　　　　　　　　　　　　　　　意味
現象：テスト担当者　　　　　　　　　　　　　　　こういう操作をしたら、こうなるはずが、それと違ってこうなった、再現性はこー。
症状：モジュール製作股はテスト担当　　　ある関数がこういう値を返さなくちゃいけないはずなのに、違うものが返ってくる
原因：モジュール、または関数製作担当　　この関数を呼ぶ前に、こっちの関数を呼ばないといけないはずなのに、呼ばれてない。
対処：しくじった人　　　　　　　　　　　　　　　　あらかじめこっちの関数を呼ぶように変更した、仕様変更は無い。

みたいに、「使ってみてどういう見えるか」、「内部でどういうふうに動作しているから」、「その動作はどこからくるのか」に
別けたほうがいいと思うです。

「同じ症状」のバグは、それで解決するかもしれないから。

それから、対応も、呼ぶほうが悪いのか、呼ばれたほうが悪いのか、
が解かるように作ったほうがいいと思うです。
こういう条件に限って、返す値を変えますとかって、ほかにちゃんと動いてる
部分の変更も必要になるし、呼ばれるほうが、「間違ってたので修正します」
って直したら、他にそこを呼んでるひとが現場合わせで対応してて、
そっちが新たにバグになったりするし。


そんな事は解かってるって言われるかもですが。