Hatena::ブログ(Diary)

shouhの日記

2015-11-30

○○駆動開発(xDD)がどれだけあるか調べてみた

はじめに

ちょっとした好奇心で○○駆動開発(HOGEHOGE Driven Development)がどれだけあるか調べてみました。

なお、説明内容は私が知っている&簡単にググったものをテキトーに理解してまとめただけなのでいいかげんです。どちらかといえば「こんな駆動開発があるよ」というポインタを示すものと考えてください。

TDD テスト駆動開発 Test

実装コードよりも先にテストコードを書く。テストコードを書くことで関数やクラスの使い方(インタフェース)を設計できるし、またそれらの動作テストも行えるため一石二鳥。

アジャイル開発の一手法であり、テスト = ユニットテスト(自動で実行できるテスト)という認識が一般的。

DDD ドメイン駆動開発(ドメイン駆動設計) Domain

ドメイン(アプリケーションが対象とする業務領域)を第一に考える。ドメイン知識を持つ人とコミュニケーションを取りながらドメインモデル(ドメインの登場人物となる用語、概念など)を作成・改良していき、このドメインモデルをベースにして開発する。繰り返し改良していくためアジャイルに開発するのが一般的。

ドメインという言葉については理解しづらい&イメージしづらいが、このたとえがわかりやすかった。

「もしキミが本当に良い自動券売機ソフトウェアを書きたいなら、JavaC言語に詳しいことも大事だけど、駅における切符の販売業務がどんなものかについても詳しくないといけないよ。」

http://d.hatena.ne.jp/takaxi/20130330/1364645339

参考

TiDD チケット駆動開発 Ticket

BTS(バグ管理システム)のチケット機能を用い、チケット基点で開発を進めていくやり方。

チケットは以下を含んでいるため、チケット単位で情報をまとめたりコミュニケーションしたりするのに適している。

  • このチケットのタイトル
  • このチケットの詳細説明
  • このチケットが絡む修正内容
  • このチケットの担当者
  • 他チケットへの関連付け
  • コメント欄

また、やりとりした過程も全て残るため、後で見返すのにも適している。

チケット機能は TiDD でなくても使用するが、TiDD はチケットを全面的かつ厳密に使うのが特徴。「俺、面倒だからチケット書きません。どうせメンバには通じてるしいいよね」は許されない。
参考

BDD 振る舞い(ビヘイビア)駆動開発 Behaviour

テスト駆動開発の一手法。期待される振る舞い(要件)を意識したテストコードを書く。具体的にはテストコード中に自然言語を書いたり、書いたそれをテスト画面で表示したりすることで「テストコードを見ただけで要件がわかる」状態にする。

比較

  • 一般的なテスト → コードの正しさをテストする(その動作が要求に沿っているかはわからない)
  • 振る舞いのテスト → そのコードは何の要件の何のために何を行うかを確認しやすくするための色々工夫する(BDDでは自然言語を書くという工夫をする)

TDD に対して、振る舞いもテストしやすくするよう工夫したのが BDD 。ちなみに BDD を支援するテスティングフレームワークは多数存在する。RubyRSpec とか。

参考

MDD モデル駆動開発 Model

モデル(アプリケーションが扱うデータの構造や設計)をプログラマブルに扱うことで作業の手間を軽減&仕様とコードの乖離を防止する開発手法

従来

  • モデルは色んな形式(excel, pdf, 手書き, 口頭説明)でつくります
  • 開発を行うにあたって、モデルは全部仕様書におこします
  • コードを書く際、仕様書に書かれたモデルの記述にしたがって、コードに落としていきます
  • このプロセスはとても大変ですし、手作業なので間違い(例:コードに反映しそれびれた)も起こります

モデル駆動開発

  • モデルには「人が読む形式」と「プログラムで使う形式(例:クラス定義)」があります
  • これらをプログラムで変換できるようにします(全自動が理想ですが半自動でもいいです、無いよりはだいぶマシです)
  • そうしたら従来よりも楽ですね。(これは全自動が出来た場合の理想論ですが)人が読む形式を作るだけでOKになるのですから

参考

UCDD ユースケース駆動開発 UseCase

ユースケースを基点にして開発するという開発手法。ゲーマー風に言えばユースケース縛り。ユースケースとはもっぱら UML で書いたユースケース図を指す。

縛りの具体例

UCDD を行うことで、ユースケースを意識した開発が可能になり、要件と実装の乖離を防止できる。

参考

FDD ユーザ機能駆動開発 Feature

まずユーザ機能(フィーチャ。クライアントにとって価値のある小さな機能)を洗い出し、その一つ一つを実装していくという開発手法アジャイル開発手法の一つ。

メリットは、開発単位がユーザ機能なので「機能Aはできた」「機能Bはまだ」「機能Cはここまでできてる」「今回は機能D,G,Iだけ実装しましょう」といったように(顧客含め)機能単位でやり取りできてわかりやすいこと。また、単位が小さいので、インクリメンタルに成果を出していける。
参考

RDD リードミー駆動開発 Readme

アプリケーションのアピールポイントや仕様を端的に示すもののが README であるが、これを先に作るという開発手法。これから開発しようとするアプリケーションの具体的イメージを利用者目線で固めることができる。

参考

LTDD LT駆動開発 LightningTalk

(開発手法というよりは勉強手法であるが)LTを作るということは、発表したい事に対して色々調査したり試行したりすることを意味する。LTを作ること自体が、発表したい事の勉強になる。

LTを作れば発表内容について勉強できる。それを発表すると聴講者から意見がもらえて更に勉強になる。また、他人のLTを聴くことで他の事も勉強できる。楽しく勉強できて最高じゃん。

参考

DDD? 締め切り駆動開発 Deadline

最初に締め切りを決めて、そこからスケジュールを決めるという開発手法

体系的にまとまった情報はアンサイクロペディアだけで、どちらかといえばネタ用語か。

参考

その他1 疲れたので名前だけ

英語版Googleで検索してヒットしたやつらについて名前だけ挙げておく。ソフトウェア開発手法と関係のないものも混じってるみたい。

その他2 同じ試みをしてる方

一名見つけた。

mike、mikeなるままに…: なんとかDDをまとめてみた
http://mikeneck.blogspot.jp/2011/07/dd.html

本記事で取り上げてないものを列挙するとこんな感じ。

  • エクセル駆動開発
  • 政治駆動開発
  • 残業駆動開発
  • 喫煙室駆動開発

まとめ

思っている以上に色んな駆動開発があってびっくりした。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/shouh/20151130/1448879024
リンク元