なんとかDDをまとめてみた

情弱なので、なんとかDDというのがどういうものかあまり良くわかっていないので、キーワードだけでもと思って、まとめてみた。

TDD

Test Driven Development

テスト駆動開発。
私が初めて知ったなんとか駆動開発というやつです。
ソフトウェアのコンポーネントに期待する振る舞いをテストとして記述して、そのテストを通るように単純に実装していく手法(間違っていたら、ツッコミをお願いします)。比較的コンポーネントが単純になるので、変化に強いソフトウェアが作成される。
代表的なフレームワークにJUnitがある。

BDD

Behavior Driven Development

振る舞い駆動開発。
TDDの発展した形態の開発手法。要求仕様を自然言語に近い形で記述し、それをソフトウェアが満たすように実装していく。
代表的なフレームワークにRSpecがある。

DDD

Domain Driven Design

ドメイン駆動設計。

'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする
出典 Wikipedia

TiDD

Ticket Driven Development

チケット駆動開発。
Redmine、Trac、JIRA、BacklogなどのBTS/ITSに登録されたチケットをベースに開発していく手法。
現在のタスクの状況が把握しやすく、VCSとの連携により、どのようなコミットなのかも関連付けて管理できる。

23:33 @diceaさんからTiDDということを教えていただきました。

2011/07/06 20:38 追加
次のなんとかDDは、ktz_aliasさんに教えてもらいました。

RDD

Responsibility-Driven Design

責務駆動設計。
オブジェクトに必ず責務を持たせて設計する設計手法。また、その責務に6つのパターンを当てはめるという方法。
全然知らない言葉だったので、こちらを参考にどうぞ。
Pinto公開に向けて #16 ― 責務駆動設計で仕切り直すことに決めた - 岩本隆史の日記帳

こっから下はネタなので注意。

EDD

Excel Driven Development / Excel Driven Design

エクセルで設計、開発。
これは実は近年のアンチパターン。
COBOLの時代には効果があったかもしれない。なぜならCOBOLは一台しかなく、マシン上でテストする場合に事前にバグを取り除いておく必要があったし、いやそもそもマシンにコードを打ち込める人など限られた人たちだけだったから。
この時の開発手法に慣れた人がExcelでのドキュメントでバグを取り除くという考え方を引きずったまま、現代の誰でもIDEを持っている環境で、この手法を使うと、面倒なことを何度もやらなければならないので、プログラマーは間違いなくやめるか、職業プログラマーになり下がる。
一方で、プログラマーを単なる代替可能なリソースとしてしかとらえていない人からすると、Excelからプログラムを算出できるのは魅力的であり、Excelからプログラムを出力することに執念をかけている人もいる。

PDD

Politics Driven Development

政治駆動開発。
どんなに完全などを現場が提案しようと、もはや決まったものは決まったものとして実施せざるを得ない開発手法。
根回し、資本関係、上司とのコネクション関係、契約関係ありとあらゆる交渉上優位になる条件を確実に抑えていって、何が起ころうとも、すでに何もかもが決定しているという残念な開発手法。
ボッチプログラマーやコネクションがないプログラマーは、たとえ決まった方針が間違っているとしても従わざるを得ない。

SDD

Smoking-Room Driven Development

喫煙室駆動開発。
会議では建設的な意見が出てこないため、喫煙室でいい加減に言ったアイデアが通ってしまうという、非喫煙者にとって最悪な開発プロセス。
喫煙室ではお客さんもポロっと本音が出るために、意外と本当の要求が聞けたりするのだが、この手法の残念なところは、その情報を得た人たちが、喫煙所で決定した事項をなんらのWikiとかメールで共有することなく動く点にある。
そのため、会議室とか作業部屋で作業している人からすると、突然方針が翻ったりして、はっきり言って、喫煙野郎を殴ってやりたくなる。

DDD

Deadline Driven Development

締め切り駆動開発。
リリース日から逆算してスケジュールを決めていく開発手法。
とくに何の戦略もないPJがとる手法の一つ。
ただただ、人材が送り込まれてくるだけで、スキルもバラバラなので、どうしようにも手が負えない。
PJの末期状態。

ZDD

Zangyo Driven Development

残業駆動開発。
最初から社員の残業をあてにしてスケジュールを組んでいる、最悪なPJの開発手法。
いや、もしくは職業プログラマーが残業手当を見越してわざと残業しているという生産性無視の開発手法。
いずれにしても、PJの後半で体力的にきつくなって、倒れる人が続出するのでやめたほうがいい。

まあ、その他いろいろあると思うので、みなさん教えてください。