テスト駆動開発における進化的設計とデザインパターンの勘所とは？〜テスト駆動開発をやめて、なお残すべき習慣とは(9)

前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って

[amapyon]

設計し続ける。デザインパターンの使い過ぎは技術的負債にもなるので要注意。デザインパターンを過剰に適用してしまったら、リファクタリングで設計をシンプルにする。

[ledsun]

TDDだと（というか自動ユニットテストがあると）、使ったことがないパターンを適用する勇気が得られるのがうれしい

[munacky]

“今の状況や抱える問題を無視して、大量にパターンを利用して解決しようとするパターン魔のダークサイドに陥ってしまうに注意して下さい。”

[indication]

結局バランスだから、使いどころを考えると悩ましい。サイクロマティック分析は単体をやらないにせよ、参考になるから、1ケースだけでも書くようにしてる。

[hate7bookmar9]

アジャイルの文脈とは関係なく、設計について考えさせられた。

[kakeda]

TDDのサイクルにパターンをどう絡めるかについての考察。文脈に合わない時はパターンをあえて使わない選択というのが大事だなぁ。つい、パターンに使われちゃうからね。