こんばんは、ちょうぜつソフトウェア設計入門を読み終わったので読んだ感想や面白かったところを残しておきます
どんな本？
AmazonのレビューやTwitterなどで、表紙とは違って骨太な内容だ..と言われていたので気になって買いました。
ソフトウェアの設計に関するさまざまなトピックを扱っていて、駆け出しからベテランエンジニアまで幅広く学びがある本だと思いました。
僕も設計についてそれなりに知っているつもりで読みましたが、認識を誤っていたところやそもそも用語自体知らなかったところが色々ありました。特にパッケージ原則に関してはそういうのが多かったです。
ちなみにくら寿司の待合室でこれ読んでたら変な目で見られました😭。。表紙がかわいいですもんね仕方ないです
どんなトピック？
近年よくTwitterとかで話題になるトピックが多い印象です。
■第1章 クリーンアーキテクチャ
■第2章 パッケージ原則
■第3章 オブジェクト指向
■第4章 UML（統一モデリング言語）
■第5章 オブジェクト指向原則 SOLID
■第6章 テスト駆動開発
■第7章 依存性注入
■第8章 デザインパターン
■第9章 アジャイル開発
キャッチーな内容や新しい定義・設計法則が紹介されているわけではなく、背景や目的に基づいたトピックの解説がメインにあります
1章がクリーンアーキテクチャなんですが、最初の章クリーンアーキテクチャなのってめっちゃ不自然な気がするんですよね。初学者向けの他の本だとデザインパターンやオブジェクト指向に関するトピックを最初に持ってきそうに思います。
僕はクリーンアーキテクチャって誤った使われ方や認識をされているイメージがあります、なので筆者的にはそういう認識をあらためてほしいという意図が強くこもっているのかなと勝手に思いました。
1章ではいきなりクリーンアーキテクチャに入る前になぜクリーンアーキテクチャが求められるのかに関する説明がありました、その後にクリーンアーキテクチャが目指すものについて解説されていました、具体的な構成例を鵜呑みにしないように注意深く書かれている印象でした。いまだにロバートさんが出した例をそのまま切り取ってクリーンアーキテクチャだと主張したり、銀の弾丸だと思って何でもかんでもクリーンアーキテクチャにしようとする記事も多いですもんね。そういう自分も過去にGoでこれぞクリーンアーキテクチャだ！最強や！みたいなのを言ってた時期があるので恥ずかしいです、
2章はパッケージ原則についてでした。正直全然知らなかったです。。言われてみれば循環する依存関係を作らないようにしたり不安定なものには依存しないようにしてる気はするんですけど、全然意識して使えてなかったです。こういう原則があるとコードレビューなどで正確に意図を相手に伝えれるので便利ですよね
3章はオブジェクト指向でした。オブジェクト指向は定義がなくて、どういうものではなくてどういうものから構成されますよー、っていう話が書かれてました、バッサリ切り捨ててて面白かったです。 しょっちゅう話題になるイメージありますよね。
僕はオブジェクト指向は多態性がほぼ全てだと思ってましたが、抽象と具象の関係性やカプセル化もそれぞれが特徴だということが読んでいてはっきりイメージできました。構造化プログラミングとの対比があったのもめちゃくちゃ良かったです。正直オブジェクト指向と比較できるものを知らなかったので
5章はSOLID原則でしたが、アンクルボブさんが言ってた「モジュールを変更すべき理由は1つである」っていう点には特に言及がなかったんですけど理解されにくいから消えたのかなぁと思いました。
というか、この文章で全て表せている気がしますね。めちゃくちゃしっくりくる
一度に再利用されるものは分散することなくひとつのパッケージにまとめっているのが、適切なパッケージ設計でした、単一責任原則はそれらのクラス版だと言うことができます。
パッケージをどのようにまとめると、後で再利用する人が困らないかを考えるのと同じように、クラスの責務は、なんかの法則で機械的に決まるものではなく、将来の保守開発への創造から恣意的に生み出すものです。設計するという行いは、この恣意的な判断と、その役目を表す最適な概念名をつけることに他なりません。一つのクラスが持つ責務の量は、この観点でデザインするのです。
6章はテスト駆動開発でした。
ケント・ベックさんの原著に書かれてたような、レッドからグリーンになってグリーンからリファクタしてまたレッドになって、のようなステップバイステップの実装例は紹介されてなかったです。僕はあれがまどろっこしく感じてるんですが同じ意見なんですかね。どちらかというとテストコードの必要性やテストコードをどう言う観点で書けば良いか、という話が随時書かれてました。
7章は依存性注入でした、この章の説明は依存性注入に関する説明の中で一番わかりやすいんじゃないかなと思いました、新人エンジニアが入社したらこれを課題図書にしたいぐらいでした。（実際に会社入社時の課題図書にしたい…）。
あと、DIしていくとなんでDIcontainerが必要になるのか、についてきちんと語られていて初学者にとって優しいなと思いました、これを分かってないとDIとDIcontainerがゴッチャになってしまうのでとても重要な記述だと思います。
逆にServiceLocatorは概念について知らなかったです。3章でもありましたけど、それは何ではないかについて書かれていると他の概念との境界線がはっきりするのでより身につきやすいんだろうなぁと今書いてて気づきました。要件定義で資料作るときにもそれは何ではないかがはっきりわかるように気をつけたいですね
あとここの章を読んでて思ったんですけど、TypeScriptってダッグタイピングなので、言ってしまえば（classを使わなければ）必ずインタフェースと実装が切り離されている言語なんかなと感じました。そうなるとTypeScriptってテストしやすいし実装の差し替えもしやすい夢の言語のように思えてきました。だからと言ってDIContainerが不要というわけではなく必要なんでしょうけど。Goもダッグタイピングって言われるけどどうなんでしょう、どちらかというと構造化プログラミングに近いからインタフェースと実装の分離はできないんですかねぇ
ちなみに書籍ではインタフェースと実装を使用の責務と生成の責務っていうふうに表現していました。
8章はデザインパターンについてでした。ところどころにfukabori.fmでt_wadaさんが同じようなことを言ってた気がします。一定のキャリアを持ってるプログラマだとみんな同じ認識を持っているみたいで面白かったです。ちなみに7章でもfukabori.fmの知識が大いに役立ちました。
Bridgeパターンは知らなかったです。実務でBridgeパターン聞いたことないしこれからも使わんのやろなぁと思ったんですけど、よく考えたら自分が単に2系統以上のものをBridgeパターン使わずに無理くり表現していた可能性があって悲しくなりました。
あと、Bridgeパターンは型の交差状態を型で表現してなくて実行時に表現してるのがモヤっとしましたがそういうもんなんですかね、
例えば金色のCupだけに特殊な処理を入れたいときはどうするんやろ？と思いました。
9章のアジャイル開発は、コラムの歴史の部分が面白かったです。fukabori.fmで話されてた螺旋の話は技術の面で見た歴史ですが、このコラムの話は設計の面で見た歴史だったので色々違ってて面白かったです、どちらもRoRが出てくるのでよほど世間に影響を与えたFWなんだろなぁと思いを馳せてました。
まとめ
エンジニアとしての設計の視野が大幅に広がったいい本でした。初心者からベテランにも誰にでもお勧めできる本だと思います！