2022/09/11

A Philosophy of Software Design読書感想

最近ようやくA Philosophy of Software Design を読み終えた。

今後ソフトウェアエンジニアとしてキャリアを重ねていく上で、大事にしたい内容が多く、まとめる意味でも感想を残す。

どんな本か

ソフトウェア開発において発生しうる複雑さへの向き合い方を教えてくれる本。

この本では

の２つについて述べることを目標としている。

少し抽象的な話が多い印象だが、それでもソフトウェアの持つ複雑性に悩まされてきた人にはこの本はとても分かりやすく、血肉になる内容だと感じた。

2022年9月時点で英語版のみだが、ページ数もそれほど多くなく、比較的平易な英語で書かれているため、読むのにそこまで苦労はしない気がする。

この本ではソフトウェア開発における複雑さを減らしていくための考え方としてdeep moduleを紹介している。

インターフェースはシンプルに保ち、より多くの機能を使うことの出来るクラスのことを指すらしい。

その反対のインターフェースが多いが実装されている機能が少ないクラスはshallow moduleと呼んでおり、筆者はshallow moduleの実装を減らし、よりdeepなmoduleを増やしていくことが複雑さを減らすために有効と主張している。

責務が小さなクラスを組み合わせて機能を実装することが良いとされている文化の中で育ったので、この主張は中々興味深いものだった。

ただ、似たような機能を持つクラスから適切なものを選ぶのは、ソースが膨大になればなるほど困難になるのは自分も感じていたので、deep moduleを目指していくことでmoduleを利用するときの認知負荷が減っていくだろうなと腑に落ちた。

筆者はmoduleを利用するときの認知負荷が減るのであれば、module自体のコードが複雑になることは許容するスタンスらしい。

ここら辺はインターフェースがいくらシンプルであろうと、コードが複雑になるのであればテストコードが書きづらくなり全貌の把握が難しくなって逆に複雑性が増さないか？とは思った。

まあでも今にして考えると、大抵仕様が複雑になるのは複数の機能を掛け合わせるときで、個々のmoduleはそこまで複雑なものが多くないかなとも感じる。

個々のmoduleの要件は明確になっていることも多いので、それぞれの要件に合うようなテストコードを書けばよくて、実装が複雑でもそこまで影響はないのかも知れない。

deep moduleを採用してインターフェースがシンプルになった分、複数機能を掛け合わせて業務要件を実現している箇所のテストコードも書きやすくなるみたいな効果もありそう。

deep moduleを意識した実装を行っていき、テストのしやすさ、メンテナンス性についての知見をためていきたいと感じた。

筆者は適切なコメントがソフトウェアの設計を向上させるとも書いてある。

どんなコメントが良いのか、悪いのかとここまでしっかり書いてある本は貴重だし、とても参考になると感じた。

特に

といった点はすぐに真似できるし、コードの質も良くなりそうだと感じた。

コメント書かない派の意見についての反論も書かれていて、自分としてはかなり納得感の強い意見だと感じた。

きちんとしたクラス設計を行っていれば、コード自体がコメントになるといった偏った考え方になりつつあったので、しっかり反省しつつ、適切なコメントを書けるようになろうと思う。

一通り読んでみて、かなり実践的かつ分かりやすい本だと感じた。

自分の中でどんな設計・コードが質の良い（もしくは悪い）ものか？をうまく言語化できていなかったが、この本はそれらの具体化に役立った。

当然、今後エンジニアを続けていくうちに意見の合わないことも増えていくだろうが、それはそれとして、1つの設計についての考え方を纏めた本としてかなり優秀なものなのは間違いないと思う。

今後も折に触れて読み返そうと思う。