ゲーム創り隊＠ど素人コミュの作品を楽しく途中で投げ出さずに創る概念inTDD

すみません勝手にトピック作りました、不要と言われれば即刻削除します。
この文はかなり長くなります、が飽きないように書くつもりです、お暇でしたらお付き合いください。
皆さん何かを創ろうとした時に色々考えすぎて結局何もしなかったりぐちゃぐちゃになったりしませんか？少なくとも自分はそうなっていました。
それを回避する為の考え方がTDDと呼ばれるものです。

○●本題●○
そもそもタイトルにあるTDDとは何のことなんでしょう？
TDDとはテスト主導型開発（Test Driven Development）の略です！(ババーン！


Σ(´Д｀ )はぁ！？　と思われるかと思います。
つまりテストを中心に開発をしろ、という事です。
更に言えば「失敗を前提に作っていく」とも言えます。
あくまで「考え方」です。

今回はプログラムで例えていますが(そもそもプログラムの考え方)絵を描くときや音楽を作る時でも考えられる事だと思います。

?まず、現時点で分かっている範囲でテストする必要がある項目をリストアップしていきます(todoリスト)このリストは随時、テストする必要がわかった時点でその項目を追加していきます。
●例えばプレイヤーキャラのtodoリストを作るとしたら
●移動が出来る・・・と言った抽象的な事ではなく
●キーの情報を受け取り左右に動ける。
●特定のキーを押すとジャンプする事ができる。
●移動やジャンプの早さ(高さ)は自分のパラメータ(速度)に依存する、と言ったようにその動作を実装するのに必要最低限の事を書き連ねていきます。

?このリストから１つ選ぶ。これは、現状で実装できそうなものを選び、テスト自体の記述が容易でも、Fake It（後述）でしかコードを記述できなさそうなものは後回しにする。
実装できそうなものが無い場合は、列挙した項目が抽象的過ぎます。
その場合、それを実装するための前提にできるような、より細かく項目を作り、リストに加えます。
●例えば、「ジャンプ中に敵の上に乗ると踏みつける事が出来る」と言ったリストを追加しても、まずはジャンプが出来なければ実装できないので後回しにします。

?選択した項目についてテストコードを記述する。このテストは、現在の実装を用いると失敗するようなものを選ぶ。
●つまり、「この機能を実装するにはあのクラスに処理とメンバ変数を追加してそれを受け取れるような関数を・・・」と考えるのではなくそのテストコード内で、「こんな関数がこんな値を返してくれるといいな〜」みたいな考え方で書いていきます。

?コンパイル(実行する事)に必要な【最小限】のコードを追加した後、実際にテストを実行し【失敗すること】を確認する。
●ここで失敗しないと意味がないのです。
●もしテストをパスしてしまった場合は、意図しない事が起こっているかそもそもテストをする必要が無い事が考えられます。

?できる限り早くテストの失敗を解消するようなコードを記述する。この段階では、テストをパスさせるためにどんなことをしても良い（ハードコード(定数を使う)、コピー＆ペースト、コードの重複等）。
●この時点では他の事を考えずにとにかく動かせるものを作ることに専念します。

?テストがパスする(コンパイルが通る)コードが書けたらテストがパスすることを保持しつつ、コードを整理していく。
●重複しているところは関数化したり、ハードコードな部分は変数に置き換えたりする。
●大体の場合ハードコードは実際にはどこからか得られるはずのパラメータの値なハズだが、ハードコードのまま変更する必要が無い場合はその限りではない。
●このコード整理の事を【リファクタリング】と言います。

?todoリストから実装した項目を削除する。
●作業中に他のテストが追加された場合は振り変わるかもしれません。


以上?〜?を繰り返しでプログラムを書いていくと非常に効率が良いです。
このTDDの目標は"Clean code that works."(コードがキレイでかつ動く)であると同時に"You Aren't Gonna to Need It."(そんな機能必要ないって！！)とされています。


○●利点●○
?前述のやり方を繰り返す事によって余計なコードが入らなくなり、かなりまとまったコードになる。

?頭で考え込む代わりにコードで具体化して進むことができる、そのおかげで確実に進捗を進めることと同時に実際には考えなくて良いことが分かってくるかもしれない。

?理想的なテスト駆動であればカバレージは100%になる。欠陥やバグは非常に少ないことが期待される。

?具象的なコードから始まり抽象化する(ボトムアップ方式)ため、適切な抽象化で抑えられる。過度な抽象化はむしろ柔軟性を失わせ、保守のコストもかかってしまう。現在の仕様に対応するだけのシンプルさを保つことで将来への仕様変更の対応が容易になる。


○●終わりに●○
長くなりましたが、ここまで読んでくださいましてありがとうございます。
プログラムをしているとどうしても汎用性を高めようと考えたり複雑に考えてしまったりで進まない時ってよくありますよね(少なくとも自分がそうです)

しかしこの考え方なら頭の悪い自分でも容易に確実にコードを書いていくことが出来ます。何よりモチベーションが保たれます。
更にtodoリストとして書いてる事により未来の自分も今後何を実装しようとしていたか忘れずに済みます。良いこと尽くめですね。この考え方を忘れずにしましょう！

○●次回予告●○
実はまだ終わりではありません(笑)すみませんまた長くなるかもしれません。
今度は【ウォーターフォールモデルとボトムアップモデルとスパイラルモデル】でお送りします。