パンくず
書籍 Refactoring to Patterns
Why I wrote this book
Test-Driven Development and Continuous Refactoring
概要
Test-Driven Development and Continuous Refactoringについて
詳細
多くの素晴らしいXPのプラクティスのうちの2つであるテスト駆動開発と継続したリファクタリングは、私の開発した
ソフトウェアを劇的に改善した。
この2つは私や私の組織の「Over-Engineering」や「Under-Engineering」を減らし。
高品質でリッチな関数でより多くの時間を作り出すことが出来ることが分かった。
テスト駆動開発トリファクタリングは対話によって動作しているプログラムを効率的に
進化させることが出来ます。
Ask：テストによりシステムに質問をする
Response:テストを通るコードを書くことで質問に答える
Refine:曖昧な部分を明らかにし、本質でない部分を取り除いたり、アイデアを考えることで改良をする
Repeat:次の質問で対話を続けます
このプログラミングのリズムにより、私の視野は開けた。
時間をかけてシステム設計のすべてのニュアンスを把握する代わりに、TDDを使用して数分か1分もかからずに正しく
動作する機能を作成することが出来ます。
Kent BeckのTDDの真言と継続したリファクタリングは"レッド→グリーン→リファクタリング"です。
この色はUnitテストフレームワークを利用すれば見ることが出来るでしょう。
その過程は以下のようになります。
Red:期待値を指揮で表したテストを書く。テストは失敗する。まだテストをパスするコードを書いていないから
Green：テストをパスするコードを書く。ポイントは重複がなく、シンプルでクリアな設計で痛みなく作る。
Refactor：テストをパスしたコードを改良する。
シンプルなテスト駆動開発はプログラミングの世界を一変させる。
未経験者は「存在しないコードにテストなど書けるのか？テストをパスしたコードをすぐにリファクタリングする必要があるのか？
これは無駄でちぐはぐなアプローチではないのか？」という。
現実にはそれと反対のことが怒る。TDDは継続した規律正しいスタイルの開発、焦点、リラックス、生産性を最大化する。
"Rapid unhurriedness"はMartin FowlerがTDDを表現した。
正しいリズムのTDDを覚えることと継続したリファクタリングは練習を要します。
私の知る一人のプログラマーであるTony Mobleyはこのような設計は
構造化プログラミングからオブジェクト指向プログラミングへ移行したほどではないが
開発者のパラダイムシフトであると述べた。
TDDによる開発は以下のような事象の助力となります。
・欠陥を低く保つ
・恐れずにリファクタリングする
・より簡潔でよりよいコードを提供する
・テスレスのないプログラムを提供します
BeckのTest-Driven DevelopmentとAstelsのTest-Driven Development:A Practical Guideを学ぶことでTDDの表裏を学んだ。
