「ちょうぜつソフトウェア設計入門」読んだらソフトウェア設計の道筋が見えた
はじめに
メーカーでシステム開発をしているはらだっちです。最近「良い設計とは？」ということについて悩み、モデリングとかDDDにとかに手を出し始めていたところ、同僚から「ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用」が良本だよと教えてもらったので読んでみました。
私のレベルと読書期間
レベル
大手SIerにて７年プロマネ・２年営業を経て転職し、フロントエンジニア３年目。SIer時代はパッケージの水平展開プロジェクトでベンダー管理を主業務としていたためため、手を動かしての開発経験が無く、設計力は皆無。転職してからはUMLを学び始めて、最近UMTP L3まで取得。今年でフロントエンジニア3年目なのでプロ意識をもって働きたい。
読書期間
届いてから18日間で読み終えました。途中でJSTQB FLの勉強やDBスペシャリストの勉強もしていたので実質15日程度で読んだのかなと思います。
感想
表紙からは想像できないほどしっかりした内容
表紙がとてもポップなイラストなので、「中身はマンガかな？」とさえ思っていましたが、中身はとてもしっかりしていました。保守性の高いソフトウェアを設計するための考え方が、クリーンアーキテクチャを皮切りに一貫して書かれている、といった印象でした。
章の順番が秀逸
一般的に良くある本では技術が登場した歴史順に順を追って説明されることが多いですが、この本は最近の整理された考え方について、理解がすすみやすい順番で章が構成されていました。具体的には「クリーンアーキテクチャ」、「パッケージ原則」、「オブジェクト指向」、「UML」、「オブジェクト指向原則 SOLID」、「テスト駆動開発」、「依存性注入」、「デザインパターン」、「アジャイル開発」といった具合です。ソフトウェアの中心に”安定”を詰め込み、安定に依存する方向になるようにソフトウェアを構成していく。そのために抑えておく原則と具体的な開発手法が理解しやすい順番に登場してくるため、難しい内容でしたが最後まで読み切ることが出来ました。
DDDについても解説されてた
まずは、DDDの用語についての解説。「エンティティ」、「値オブジェクト」、「サービス」、「ファクトリ」、「リポジトリ」。普段何気なく使っている用語ですが、章の冒頭でDDDの文脈ではどういう意味なのかちゃんと書いてあり、とても親切でした。また、DDDとは要件定義・分析・設計・実装・テストを同じフェーズで行っていくことだ、ということもしっかりと分かっていなかったのでアハ体験でした。ウォーターフォール経験が長く、どうしてもフェーズに当てはめたくなったり、区切りが無いとそわそわしてしまうのですが、大事なことは実際に動くプログラムで、そこから得られる知見を最大限活用して次につなげる活動なんだなと再認識させられました。 1つ分からなかったのは、実践的モデラーとはスクラムの文脈だとどのロールにいるのかな？と思いました。開発者なのか、POなのか。その辺りどなたか詳しい人がいたら教えてください。
理解できたこと・気づき
安定に向かって依存の方向を揃えるということ
UMLで依存の矢印が出てきますが、もともとは単に「どっちのオブジェクトがそれを使うかわかるようにしてる」くらいの理解しかありませんでした。オニオンアーキテクチャを知ったあたりで「リポジトリ層で依存を逆転させるんです！これが重要なんです！」って聞いて、分かるようで「なんでそれがそんなにいい事なんだろう」とも思っていました。
この本を読んで、「ドメインのコアに安定を詰め込む」その安定に他の層が依存していくことで高凝集・低結合となる、ということが理解できました。
テスト駆動開発は設計手法
TDDってワードは巷では何百回と聞いていました。「アジャイルにやりたいなら自動テストは当たり前。回帰テストでデグレが確認できるからね。だからTDDは重要なんでしょ。」と思っていました。しかしながらTDDの意味合いは全然違って、より良い設計に導くために必要な手法だということに気づかされました。
依存性注入の考え方について
DI(Dependency Injection)という言葉も聞いたことはあったのですが深くは理解できてませんでした。そして依存関係逆転の原則（dependency inversion principle）についても。
いやー、なるほど。DIを実装ことによって依存関係を逆転することが出来、より疎結合になる。そのためには単体テストがしやすくなってることが重要、だからTDDも重要。色んな知識がこの本を読むことで結び付けられました。
クラスと高階関数について
普段の業務でReact / Nextjsを使っていて、どのようなソフトウェア設計をすべきなのか常に悩んでいます。オブジェクト指向をどの本で学んでもクラスが出てくるので、業務ロジックを書きたいなら同じようにクラスを使えばいいのかな？と感じます。幸いjavascript / typescriptでもクラスは書ける（厳密にはprototypeベースかもしれないが）のでそうすればいいのかな、と思います。 しかしながら、社外の有識者に「Reactにおいてクラスを使うのはあまりモダンではない、Reactの一般的なお作法で書いた方が良いのでは？」と言われたり、エンジニアからも「Reactは関数型プログラミングだよね（良くわかってないけど）」と言われたり。そして、stateやhooksと言った状態管理・副作用管理の機能もあるため、頭の中で「どうやって書くことが保守性の高いソフトウェアに繋がるのだ？？？？」と大混乱が起こっていました。 まだ、その霧は完全に晴れてはいないのですが、１つこの本で気付いた大きなことは「高階関数で振る舞いが渡せる」ということです。これはクラスでなくても依存性注入と同等のことが出来るということだな、すなわち高凝集・疎結合を実現する手段の一つだなと理解しました。
終わりに
自分がどれだけ理解できているのか確かめるためにブログにアウトプットしているのですが、書けば書くほど、「ん？やっぱりよくわかってないな」という点がいっぱい出てきて改めて奥が深いなと思います。再度本を振り返りつつ、”安定に依存する”という大原則を胸にこれからも学び続けたいと思います。
