DDD / Timing

タイミング (p.324) †

要約 †

• 変化が必要であることを確実に正当化できるまで待っているようでは遅すぎる。
• 継続的なリファクタリングはベストプラクティスであると考えられるようになってきているが、ほとんどのプロジェクトはまだ尻込みしている。その理由は、コードを変更するリスクと時間的なコストであるが、あやふやなデザインのまま先に進む方がリスクは高い。ソフトウェア開発は先まで見通せるようなものではないのだから、コードを変えるコストと変えないリスクはどちらが高いか分かるはずだ。
• より深い洞察のためのリファクタリングはドメインに対する探究のプロセスに組み込まれなければならない。リファクタリングの契機はこんな時：
  • チームのドメインに対する現在の理解をデザインが表していない時。
  • 重要な概念がデザインの中に隠れてしまっている時、もしくは
  • デザインの重要な箇所をより柔軟にできるチャンスを見つけた時。
• このような積極的な姿勢は良いが、いつでもどんな変更でも加えてよいということではない。
  • リリースの前日はやめなさい。
  • 技術的な思いいれによって柔軟なデザインを導入し、ドメインを犠牲にしてはならない。
  • どれほどエレガントであってもドメイン・エキスパートが納得しない「深いモデル」を導入してはならない。
  • 物事に固執してはならない。リファクタリングを好む習慣をつけなさい。

担当者のつぶやき †

• キーワードは、CHANGE。最近よく聞く気がしますが（笑）

みんなの突っ込み †

まとめ (議事録) †