TDDのデメリットを整理する－自分のためのメモ－

TDDとはいわゆるテスト駆動開発ではなく、トラブル駆動開発のことです。

テスト駆動開発を実践している方、模索している方、並びに35歳未満の健全な青壮年の方はブラウザの戻るボタンを押して速やかに退場してください。

：

概要

トラブル駆動開発 (トラブルくどうかいはつ、trouble-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にコードを書き、それがひと通り動作するとコーダーが納得する程度の実装をとりあえず行った後、共有するリポジトリにコミットし、後工程のテストもしくはそれよりも早いタイミングでの機能間担当者間のマージで発生するエラーを契機に、関係する開発者でコードを見なおして修正する、というサイクルの工程をなんとなくウォータフォール型の工程間に織り交ぜて、工程を推進するすスタイルである。

ウォータフォール型ソフトウェア開発手法の亜流として発生し、「編集して祈る」しかできない哀れな子羊たちを今日も疲弊させている。

特徴

VCSを使っていないか、あってもブランチは１本だけである
品質を担保するのは常に後工程である
品質が評価されるのは納品直前(場合によっては納品後)である
暗黙の掟として、不具合は発見した人が対策する
開発者はマージが怖いため、ローカルで変更貯めこむ傾向にある
変更を貯めこむためさらにマージリスクが大きくなる
開発者はローカルでソース管理を新たにやり始めている
神に祈ることに既に抵抗がない

デメリット

トラブル毎の調査工数が無駄に多くかかる

どのコードも品質が確保されていないため、マージ直前までの他者のコミットのせいなのか、自分のコードのせいなのか、組み合わせ問題なのか、設計の問題なのかわからない。そうすると最小限の正しい所がないために調査範囲が広くなり原因の究明に時間がかかってしまう。

トラブル対応は予定されていない工数、追加の原価消費となる

ウォータフォールのテスト工程だと不具合は想定されるが、トラブルは想定外として計画されないことが多い。計画時はトラブルなどおこらないと楽観的なことが多い。結果的にプロジェクトは赤字になることが多い。

トラブルは残業対応が原則であり、開発者は疲弊する

トラブルは開発側に起因する遅延となるため、納期の調整は許されない。常に開発者は残業対応が求められる。開発者は自分がババをひきやしないかと、怯えながらSVNの更新をし、えぇいままよとコミットする。

プロジェクト期間中は残業が常態化し、体力と睡眠時間を削がれ、やる気も失っていく。

コードはさらに汚れていく

時が経てば経つほどに「つぎ」が大きく多くなり、より保守性は失われていく。そしてさらにトラブルの調査がストレスな作業になってゆく

原因と責任の所在が不透明

メリットと考える人もいるだろう。この開発手法は全ての人が「頑張っている」。みな遅くまで残業している。時間がかかった…なかなか手がまわらなかった。仕方なかったねで終わってゆく。不具合が起こるのは確率的に当然とする前提からすると、この赤字、納期遅延、品質（機能性保守性）低下の原因がどこにあるのかとても究明しづらい。また、繰り返す可能性が高い。

メリット

少なくともコードは統合されていて、ただひとつである
統合された物があることに安心感を得られる（まやかしだが）
プロトタイプ的にお客様に見せることもできる（ここまでできてますよ）

いつでも組み合わせテストをできる、プログラムの出来具合を外部仕様の目線で確認できるということである。これはウォータフォールの下流の組み合わせテスト、システムテスト工程の担当者、開発の最終アウトプットの品質や進捗を把握したいPLにとっては非常に心強く感じるもののようである。対象が早い段階で見えるというのはなんとも頼もしい。

：

トラブル駆動から抜けださねばらない。今まで自分とともに開発してきたたみなに大変な苦労をかけてきていたことを謝りたい。こんなダメ手法は俺の代で終わればいい。