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