恥知らずなTDD使いがいた！
俺はRDDを使い手なんだがプロジェクトリーダーがが残念なことにTDDを使ってきたので「お前それで良いのか？」と言うと「何いきなり(テスト書かずに)実装してるわけ？」と言われた。
俺の前プロジェクトチームがTDDの熟練者なのだがおれはいつもデスマーチにするから気の毒になったので聞いただけなんだがむかついたので「お前中身が空のテストでボコるわ・・」と言ってプロジェクト開始直後にバグを溜めてコミットしたら多分リアルでビビったんだろうな、、カバレッジ測定してきたから無視してｶｶｯとコミットしてから障害だしたらかなり青ざめてた
おれは一気に次の実装をしたんだけどリーダーがテンパってておれの作業を見失ったのか指示出してこなかったから独自インデントでコーディング規約を崩した上についげきのオレオレデザインパターンでさらにプロジェクトへのダメージは加速した。
わざとチームから距離をとり「俺はこのまま納期に間に合わなくてもいいんだが？」というとようやく必死な顔してなんか部屋のはしっこにプログラマ増員してきた。
チームは必死に仕事するが、時すでに時間切れ、マジックナンバーと謎のif分で固めたスパゲッティにスキはなかった
たまに来る効果的なリファクタリングもコンフリクトで撃退、終わる頃にはズタズタにされて白髪の増えたメンバーがいた
ふと思ったこと
xUnit,Jenkins,tracなどのアジャイルプロセスのためのツールを使っていないプロジェクトがありました。
でも、こまめなデプロイ(機能リリース)を繰り返してCIっぽくうまくいっていたことに気付いたので。
RDD (Release Driven Development) リリース駆動開発
リリース駆動開発とは
とりあえずリリースして様子を見る開発手法である。
手戻りに強くすばやいリリースが少ないリソースで可能。だが一歩間違えると単なるTDDのアンチパターンになるという諸刃の剣。素人にはお勧めできない。
RDDで開発を行う理由
既にレガシーコードのシステムが稼働中
テストを書くためには大掛かりなコードの修正が必要だったり、進め方を変えるのに偉い人の判断が必要だったり、なんかいろいろと壁があってTDDに切り替えられない。
TDDで開発を進めるのはプログラマ個人の問題だったりするのでそんなに問題にはならなそうですが、既存のものにテストを書いていくとなると話が違います。
開発担当者が全体を把握しているので何とかなる
長い時間をかけてコードが育つのを、特定のエンジニアがずっと見てきた場合。てゆか育ててきた場合。
ハウルの動く城みたいなコードベース。 誰が見てもとっちらかってるけど作った本人は中身をよく把握してて、掃除されると逆に大変になるみたいな。
ツールじゃないんだ、人なんだ
TDDやCIの手法やツールなしにうまいことプロジェクトが回っていた理由。
あとでかく。
→ 書いた RDD (Release Driven Development) リリース駆動開発 - くろまほうさいきょうでんせつ
