前回のふりかえり
第12章 デザインパターンをモデルに関係づける
第13章 より深い洞察へ向かうリファクタリング
より深い洞察へ向かうリファクタリングを行うには
これは多くの側面を持つプロセスだが、重点的に取り組むべきは下記の3点
開始
より深い洞察へ向かうリファクタリングは、さまざまな方法で始めてよい。
- コードをきっかけにした開始方法
- コードの持つ問題(複雑やぎこちなさ)への対応
- ドメインモデルをきっかけにした開始方法
- モデルの言語がドメインエキスパートと切り離されているように見える
- 新しい要求が自然には適合しない
- 学習の結果発生する開始(より深くドメインを理解するようになることで、モデルをもっとわかりやすくする機会を見出す)
問題のある場所を発見することで、開発者は新しいモデルの要素を体系的に探し出せるようになる。
それには下記のような方法がある
- 同僚やドメインエキスパートとブレインストーミングする
- アナリシスパターンやデザインパターンなど、本に書かれた体系的な知識を利用する
探究チーム
意図を明確かつ自然に伝達するようモデルを改良する方法を探し出す
- 従来のリファクタリングであれば、数時間で終わるわずかな変更でも十分
- 新しいモデルを模索するには、長い時間がかかり、多くの人々の参加が必要となる
探究の方法
- 変更を先導する人が開発者数人を選び出す
- その種の問題を考え抜くことを得意とする人
- ドメインの中の該当する領域に精通してる人
- このグループで30分から1時間半のブレインストーミングを行う
- UML図のスケッチ
- オブジェクトを使用してシナリオのウォークスルーを試す
- 主題に関するエキスパートが、モデルを理解して役に立つと思っていることを確認する
- コーディング。もしくは数日考えることにして別の作業をする
- 数日後再びウォークスルー
- それまで考えたことを寝かせているから、初期段階よりも結論に至る可能性が高い
- コーディング
探究のプロセスを生産的なものに保つポイント
- 自主的な意思決定
- 少人数であれば小回りが利く。
- スコープと休憩
- 数日の間隔をあけて短いミーティングを数回やれば、試す価値のある設計が作り出せるはず(長引かせる意味はない)
- ユビキタス言語の駆使
- ブレインストーミングの中で、ユビキタス言語を実践し、改良する機会が生まれる。
リファクタリングのタイミング
リファクタリングは、先延ばしにすると変更するのがより困難になる。 下記の場合にはリファクタリングしてしまうこと。
- 設計が、ドメインに関するチームの現在の理解を表現していない。
- 重要な概念が設計で暗黙的になっている(そして、どうすれば明示的にできるのかまでわかっている)
- 設計において重要な部分を、よりしなやかにするチャンスがある
ただ、リリース前日だったり、ドメインエキスパートを納得させられなさそうな時にはリファクタリングすべきでない。
その他諸々のメモ
- より深い洞察へ向かうリファクタリングは、継続的なプロセスである。暗黙的な概念が明示的になり、設計の一部がしなやかになる。そのようなリファクタリングの中でブレイクスルーが起き、深いモデルへと進化することもある(ただ、意図して起こすことはできない)
- 車輪の再発明が常に必要なわけではない。ドメイン自体に関する文献やアナリシスパターン等からアイデアを得ることもできる
