先に書いておくと、交換ブログは後で（多分昼間）書きます。
10/17(金)に、ソフトウェア設計の結合バランスが届きました。
割と読み進められそうだったので、3章くらいまで読みました。
最近Nagano.devの輪読会で
「技術書」の読書術 達人が教える選び方・読み方・情報発信&共有のコツとテクニックを読んでいるのですが、その中に音声によるインプットとかそういった話があったので、「読んで口に出して声を聞く」みたいなことをしてみました。要するに音読です。
自分はTRPGを最近またやるようになったのですが、GMもまたやりたいと思ってるのでその練習も兼ねたり滑舌を良くしたりする意味でも音読結構良かったので、できる本は音読していこうかなと思いました。まあうるさいですが。
さて、本の中身ですが最初は「複雑性」の定義から始まります。
第2章でクネビンフレームワークというものがでてきて、要件定義のあたりにも触れる話があったのでPjMやってる身としてはここだけでも十分面白く、新しい考え方を得られたのでめっちゃ勉強になりました。
このクネビンフレームワークをエンジニアの場合に落とし込んだ内容が書いており、わからないことの分解の仕方がまた1つわかったような気がします。分解の仕方のレパートリーが増えたみたいな。
細かい話は書籍読んでくださいって感じなんですが、
- 自分がわかること＝明確系
- 分からないけど分かる人がいるとわかってること＝煩雑系
- 分からないし分かる人がいない＝複雑系
- ヤバい状況だから一旦脱する＝混沌系
- どれに分類するかすらわからん＝無秩序系
と解釈しています。あってるかな、また読み直そう。
業務で別PJでA/Bテストやってるのを把握しているのですが、複雑系を読んだときにその話があったのでとりあえず話の理解は概ねできていそうです。
ちょっと難し目の内容かと思ってビビってたのですが、思ったより読みやすく内容もなんとなく分かったような気がしています。
まあまだ3/15章なのでこれからどんどん難しくなる気がしますが、第3章まででも十分読む価値があると思ったので読んでよかったです。この先も分かったらいいなぁってキモチ。
第3章で複雑性から結合の話がまざってくるのですが、リポジトリパターンは普通に実務でも使ってたのですんなり理解できてよかったです。「あ、あれリポジトリパターンだったんだ」と気づけました。
大域的複雑性と局所的複雑性のところは、どっちを優先するかケースバイケースだろうなと思いつつ、カプセル化を重要視するなら局所的なのかなぁとふんわり思ったり。サービス同士の結合で考えるなら大域的だとわっちゃわっちゃしそうなので局所的にして見えないようにするのがいいんじゃね？みたいな。マイクロサービス的な考えだと思いますが、多分。
自分としては落とし込めてると思っているのですが、それが正しい解釈かの自信はまだないのでもう1回読み直したほうが良いかもなぁとまだ読み終わってないですが思ってます。
とりあえず、結論として、面白い本です。
