第17章 私のアプリケーションには構造がありません
寿命の長いアプリケーションは、無秩序になりがち
最初のアーキテクチャも徐々に崩壊していく
アーキテクチャを保つためには、チーム全員がアーキテクチャを知り、関心を保つ必要がある
大規模なシステムの全体像を理解する方法
- システムのストーリーを話す
- システムのアーキテクチャを説明する
- 説明役は重要な箇所から順にシステムのアーキテクチャを簡潔に伝える(重要な箇所全部)
- 簡潔に伝えるためには、単純化する必要がある
- 説明役は重要な箇所から順にシステムのアーキテクチャを簡潔に伝える(重要な箇所全部)
- システムのアーキテクチャを説明する
- 白紙のCRC
- CRC= クラス(class),責務(Responsibility), 協調(Collaboration)
- 白紙のカード的なもの(手元にあるなら何でもいい)を一つのインスタンスとして表現する
- 入出力などのコレクションは重ねて表現する
- 会話の吟味
- 設計に関する会話に耳を傾けて、話しているコンセプトはコードのコンセプトと同じかどうかを気にかける
- もし、しっかりと共通する部分がないなら、チームの理解がコードに反映されていないか、チームがコードを誤って理解している
感想
rails wayってこういうところだと効くのかな
設計思想が一貫して理解されていようとも、動的型付けが辛くなってくる(あと速度も)