Clean Architecture、ネットで内容をちらちら見ていたのですが、しっかりと内容を把握したいと思って本を購入したので忘備録を兼ねて気になった部分の感想を書きたいと思います。まだ途中なのですが、基本的なアーキテクチャの原則が描かれている本でありちょうど学びたい内容が描かれていてかなり良いと感じています。 まだ、4章までしか読んでないので、とりあえずそこまでで。
第一章 設計とアーキテクチャ
優れた設計の目的と優れた設計とは何を表している章。最初の章なので導入的な内容。でも何が目的で設計するのかを考えることは大切だなと思いじっくりと読んでみる。 ざっくりと書くと少ない労力で改善できたら良い設計で、リリースするたびに労力が増えるなら悪い設計とのこと。 設計の良し悪しを労力で考えるというのはあまり考えてなかったのですが、たしかに改良にかかる労力が少なくなるためだと考えるとエンジニア・経営者双方で設計をよくするモチベーションになるので良いなと思いました。
この章で出てくる図が気になって調べてみたら2011年の発表されてた図みたいですね。（参考）TDDを実施したほうが実装時間が短くすむってのはなかなか興味深いなぁ。TDDはテストとともにコードが進んでいくので、自然と疎結合な良い設計のアプリができていくからかなぁとぼんやりと思いました。
第二章 2つの価値のお話
この章ではソフトウェアの価値と何かを表している章。その価値とは「振る舞い」と「構造」をここでは上げていました。ソフトウェアって絶対に作って終わりではないので、変更可能なソフトウェアにする「構造」って確かに重要だなぁ…としみじみ思いました。この章みてると闘争ってワードが出てきて歴史的にもアーキテクチャとソフトウェアの振る舞いとの天秤で苦労してきたんだな…としみじみ。
第三章 パラダイムの概要
構造化プログラム、オブジェクト指向プログラミング、関数型プログラミングの3種類のパラダイムについて紹介している章。プログラミングパラダイムが何かを与えているのではなくて、規律を与えて何かをやらなくするようにするというのは面白いですね。考えてみればフレームワークもできることを束縛してその範囲で生産性を上げるとかしているなぁと考えるとなるほどと思ったり
第四章 構造化プログラミング
この章から各プログラミングパラダイムについての説明が始まりました。構造化プログラミングの提唱者ってダイクストラだったの知らなかった…ダイクストラ法ってイメージが自分の中で強かったな…
ここで一番興味深いなって思ったのが、「テストはバグが存在しないことではなく、テストはバグが存在することを示すものである」って言葉だった。テストをどんなにやってもバグが見つからなかったから正しいだろうってことでプログラムの正しさを保証してるってのはなるほどなーと。テストをしたから正しいってのは自分の中ではしっくりきてなかったんだけど、こんだけテストしてもバグ出なかったなら正しいだろ~って考えはなんとなくしっくりきましたね
とりあえず読んだのはここまで。はやくⅢ部の設計の原則にたどりつきたい。
