テスト駆動開発における進化的設計とデザインパターンの勘所とは？〜テスト駆動開発をやめて、なお残すべき習慣とは(9)
前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って
「構え、撃て、狙え！」さっさと動くものをつくって、小さく素早く失敗するして学ぼう
Photo credit: Dushan and Miae via Visual hunt / CC BY-SA今回は、前回紹介した『UNIXという考え方』の続きで、定理の一つのご紹介です。「初期から動くものをつくってフィードバックをもらって、軌道修正しながら、ゴール見つけて達成しましょう」は、アジャイルな開発でも指摘していますが、Unixの哲学でもその重要さが語られています。 定理3:できるだけ早く試作を作成する ソフトウェアを使って、誰向けに何の問題を解けばよいか、どう解けばよいか、予めはっきりと分かっているのであれば、わざわざトライアンドエラーで失敗しながら学ばなくても、一度立てた計画通りにものごとをすすめることができるでしょう。例えば半年間の開発の初期段階で仕様・設計を作成して固定し、実装・テストして完成させる計画を立てても実現できるはずです。 ところが、終盤に実際に動くものを見て
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
