http://blogs.wankuma.com/jitta/archive/2006/09/04/37657.aspx
http://blogs.wankuma.com/ognac/archive/2006/09/03/37537.aspx
プログラムの質の向上,仕様書通りの品質維持。という基礎意識が低迷し,単なる納品物という意識で作成するケースが多いように思います。
----引用▼
とはいえ、現実問題として、「１キロ ステップにつき、テスト項目が何件以上」とか、「１キロ ステップにつき、発見バグ数が何件以上」とか、定義している会社が多いんですけどね。でも、IDE が進化して、自動生成コードが多くなると、「ステップ数」って、何を根拠に求めるんでしょう？
----引用▼
という指針があるものだから, バグを捏造し,意図的に不具合箇所を仕組むプログラマがいたりするのです。
テストドリブンが注目されていますが、これが成果を上げる前提条件は、業務仕様が確定していることです。
当然のことなのですが、仕様不確定のまま開発フェーズに突入することが起こりがちです。(ognacの周囲だけだといいのですが。)
経験値では 7割前後の確立で,仕様がアヤフヤ(肝心な箇所も) のまま開始し, そのうちの何割かはデスマーチに突入しています。
プログラムの結果を見て、業務ルールを確定する顧客もいてはる...(どうなってんねん)
エンドユーザーが業務的な正解パターンを確定しかねている現状を目撃すると、テストって何? 正解の姿って何? となります.
「コードを変更するときは,変更前をコメントアウトで残し,決して削除してはならない」というコーディング規約の経験があります。
ソースの量が増える一方で, とても追いきれませんでした。
ある処では、コードカバレッジを使って,カバー率を高める..... 開発者が自分のロジックミス発見のために埋め込んだ Assert文が実行されない指摘し,
このソースは駄目だと却下されたそうです(これは伝聞)
こんな末梢部分を重要視しされている本末転倒な業務開発の実態が現実にはあるので....orz
テスト駆動/XP/アジャイルなどの手法論がまともに論議ができるよう業界を浄化していきましょう。