オープン・クローズドの原則

■所感
率直な感想は、「ここは大事なところ」だった。事前の情報で、20章くらいまでは読み飛ばしても大丈夫と聞いていたが、章を進めるごとに重要度が増している気がする。

既存の成果物に影響を出さずに拡張可能であること。

これは保守開発においてとても大切な考え方だと身に染みて理解している。ただ、設計時点でアーキテクチャというルールを適用してこその話だな、と思ってしまう。データの流れを整理して、著者のように処理の流れを図式化すれば可能だろう。ただ、これはなかなか、、、一人でやれることではない。ボトムアップは難しいと感じた。トップダウンであれば、鶴の一声じゃないがそれっぽい形にまとまるだろうけど。。

現場にいていつも思うのが、ベテランという域に達した人はあまり新しいことをやりたがらないように思う。マネージメントを行う人や管理者は、クライアントの視線を感じているだけに、「今すぐに動くもの」を作りたい。自分自身、「既存の成果物に影響を出さずに拡張可能な」プログラムを作りたいけど、それが優先度高なのかと問われると、即答できない。おそらく、あいまいに答えて終わりにするだろう。

よくないとは重々承知しているんだけど。。なので、とても大事なところ、として覚えておきたい。

■内容について
図解がとにかくわかりやすい。インターフェイスに対して、白抜きの矢印で結合個所を記載しているので、依存関係が一目でわかる。技術書って、読みやすい＝中身が薄いパターンか、読みづらい＝中身が濃い（※1）パターンが多いので、読みやすくて中身が濃いという書籍にはなかなかたどり着かない。エンジニアは小説家や先生ではないのだから、当たり前の話なんだけど。

※1 翻訳家が意味を理解していないパターンもある。あとは、専門家の話を録音して、書籍に落とし込んでいるパターンの専門書。これも、書き手が意味を理解していないと意味がない。

ところで、この図解ってなんていう名前なんだろう？コンポーネント図っぽい感じもするが、より直感的にわかりやすいので、自分用の覚書メモ作図で使用してみようかな。。