○○駆動開発 自分なりにまとめてみました(ShanonAdventCalendar2016 - 19日目)

このエントリーをはてなブックマークに追加
こちらは、ShanonAdventCalendar2016 19日目の記事です。
こんにちは、シャノンに入社して初めてブログを書きます、titoです。

今回は、もう少し自分に合った形の開発手法とかあったりしないかなぁなんて
思ってた事もあったりだったので、○○駆動開発についてまとめようと思います。
内容はそこまで詳しく無いので「こんなのあるのかー」くらいのとっかかりになったら、、、

個人的にはポエム駆動開発や、証明駆動開発が今回初めて知った手法なので
目からウロコな感じでした。

テスト駆動開発

ユニット(単体)テスト等のテストを最初に書いて、それをパスするようにプログラムを実装する手法です。
テストを書くタイミングでどういった挙動をしていれば良いかを書くので、
プログラムを実装するタイミングではテストが通る事だけ考えれば良い為、比較的楽に書ける気がします。
ただ、自分がやろうとした時は、テストを書く段階でどんな関数にするのか設計しきれず
後から後から関数が増えていく形になってしまい、いまいちテスト駆動開発できなかったりしました。。。

モデル駆動開発

UMLのクラス図や、シーケンス図等の図を用いて、そのプログラムで何ができるのか、
またはどんな情報を持っているのかプログラム実装前にあらかじめ定義しておく手法です。
仕様書等の文章と比べて、慣れれば図形の為、パッと見て理解しやすいはず。
その為にUML等の共通認識が必要になります。
図形なので俯瞰的に見たりする事もでき、問題点や矛盾を発見しやすいと思います。

チケット駆動開発

作業を細かい単位(タスク)に分割して、Redmine等のバグ管理システムで管理する手法です。
先にタスクを洗い出しておく事で、作業のやり忘れ等を防ぐ事ができます。
また、偉い人などがバグ管理システムを参照する事で、
進捗具合を見る事ができるというのもメリットの一つかもしれません。
(いちいち聞かれないで済みますね!)
規模の大きいプロジェクトになってくると、チケットの管理だけでも
結構時間がかかったりするので、工夫が必要になります。

ドメイン駆動開発

ユビキタス言語という共通言語を用いて、プロジェクト内で
コミュニケーションの齟齬が起きないようにする事、
ドメイン層のモデルにビジネスロジックを集約して変更に強くする事が特徴の手法です。
自分も少し調べた程度でやってみた事はないのですが、プロジェクト内での
コミュニケーションが円滑になるだろう点が良いなと思います。
一人で仕事をする方はきっと少ないでしょうし、障害等の問題が起きた際でも
非エンジニアの方にも話が共有しやすいというのは魅力的かと思います。

ビヘイビア駆動開発

テスト駆動開発から派生したもので、振る舞い駆動開発とも呼ばれます。
テスト駆動開発はユニットテストを最初に書きましたが、
ビヘイビア駆動開発では振る舞い、シナリオテストのようなものを最初に書きます。
例えば、メール送信の機能を開発しようとした時に、AさんとBさんにメールを送信し、
結果のデータとしてAさんとBさんのメール送信履歴が作成されているのを
確認するシナリオテストを先に用意する、といった形だと思います。
この方が実際にプロジェクトの要件を満たせているのかしっかりチェックできる
という事が利点なのだと思います。

ユースケース駆動開発

ユースケース図を作成して、開発しようとしているシステムが
どのように使われるのか定義してから開発を行う手法です。
ユースケース図からロバストネス図を作成して実装につなげていくようです。
ロバストネス図はユースケース図よりも、より実装に寄った図になっています。
エンドユーザーがどのように扱うのかを先にしっかり決めておく為、
プロジェクト内での認識の齟齬も発生しにくいのが特徴です。
リリース後、担当が変わった後の引き継ぎでもロバストネス図があると
実装の理解が早そうです。

リードミー駆動開発

先にREADME(ドキュメント)を作成して、そこから開発を進める手法です。
モチベーションの高いうちにドキュメントを作成する事で、
実装が終わってからのドキュメント作成という暗黒期間を回避する事ができます。
後からドキュメント作成するのが大変面倒なのは自分だけじゃないですよね?
READMEがある事で他の人にも情報が共有しやすいという特徴もあるかと思います。

ユーザ機能駆動開発

ユーザー機能を軸に、開発工程(設計や開発)を繰り返して進めていく手法です。
価値があると判断されたユーザー機能から優先して開発が進められるので、
早期に重要な機能の確認ができるのが良いところでしょうか。
他にも機能毎にマイルストーンが定義されており、
各機能の進捗度合いが把握できるようになっていたりもします。

締め切り駆動開発

夏休みの宿題のような、締め切りに追われる焦りを利用した手法です。
当然、デスマーチの状態になるので誰も幸せにはなれないと思います。
焦りから設計も雑になるでしょうし、技術的負債をかかえる事になるでしょう。
という事で、締め切りには余裕をもって開発を進めたいですね。

REPL駆動開発

対話式に実行できるREPL(Read-Eval-Print Loop)を実行しながら開発を進める手法です。
いわゆる、1行ずつプログラムを実行するアレですね。
この開発手法の場合、すぐに動作を確認しながら実装が進められるのか利点です。
いちいちサーバーが起動するのを待ったりしなくても、
REPL上で確認した事を書いていくだけで実装ができます。
ただ、長々とREPLを使い続けると変数がまだ残ってたりして
誤作動を起こしたりする事もあるようですね。

LT駆動開発

いわゆるLightning Talk(LT)を軸にした手法です。
開発を進めていくと、LTの為の資料もできあがっていくと思われる為、
他の方への共有が行いやすいのが良いと思います。
また、LTを行う日時が決まれば、締め切り効果で
モチベーション高く開発を進められると思います。

ポエム駆動開発

自分も調べるまではネタっぽい手法だと思ってました。
信じられない方、「ポエム駆動開発」で検索してみて下さい。
そこには―――人々の熱意がありました。

...少しふざけました。その名の通り、先にポエムを書いてから開発を進める手法です。
ここで言うポエムとは、ビジネス文章としての体裁を気にせず、
書き手の理想や、熱意、危機感といった何らかの感情を用いて
表現した文章や図面の事を指します。
文章としての網羅性を優先させず、いかに開発しようとしてるものが
楽しいものであるのかであったりを記載するので、
モチベーションを呼び起こすようなものになるのだと思います。
初心忘れず、というのが守る事ができそうで良いですよね。
エンタメ系の開発に向いているのかな、と思いました。

証明駆動開発

満たすべきプログラムの性質を記述して、それを証明するように
プログラムの実装を行う手法です。
実際には、性質を記述した後に、Coqという定理証明系支援言語で実装を行い、
性質を証明した後に他の言語に変換を行っていくようです。
プログラムの性質を証明する事ができれば、テストの記述は必要無いそうです。
やはりテストケースを実装していても抜け漏れや
レアケースを見逃してしまうという事はままあるかと思います。
テストなしで、バグが無い事を保証できるのはすごく魅力的ですね。
難易度は高そうですが、、、
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...