こんにちは。ダイの大冒険エンジョイ勢のbun913と申します。
わたしはSDET（Software Development Engineer in Test）という職種で働いており、テスト自動化だけでなく、システムの品質を向上させるための様々な活動を行っています。普段からプロダクトコードをゴリゴリ書く仕事ではありませんが、あくまでテスト側にメインで従事する開発者の意識に比重を寄せて業務を行っています。
今回は A Philosophy of Software Design という洋書を読了したため学んだことなどを書きますが、本書は英語で書かれているため「ハードルが高いよ」と思う方に少しでも役に立てるようにおすすめの読み方なども合わせて紹介したいと思います。
| Key | value |
|---|---|
| タイトル | A Philosophy of Software Design |
| 作者 | John K. Ousterhout |
| 出版年 | 2021年7月 |
おすすめの読者
以下は私自身の本書を読み始めた動機にもつながるものですが、以下のような方におすすめです。
- ソフトウェア開発者
- Agentic Coding にしろ Vibe Coding にしろAIエージェントを活用して普段の開発を行っているなかで提案されるデザインやコードに関して悩みを抱えている
- 初めて読む専門書の洋書を探している
私も Claude Code などを活用して日々の開発を行っています。そんな中、私自身に設計の知識がなければ広範な知識を持っているが適用の仕方を持て余しているエージェントに対して適切な方針を示してあげることができません。
- 私がこのシステムに対して良いと感じている設計方針はこれです
- ソフトウェアテストをする際には、特に境界値分析・状態遷移テスト・デシジョンテーブルの技法を活用してユニットテストを書きましょう
- ユニットテストにおける実装方針として、極力フェイクを使って常にテストを走らせても気にならないスピードで開発にフィードバックを与えられるようにしましょう
具体的な例を出さなくても、これらの概念を話すだけでAIエージェントに私が良いとすることを短い言葉で伝えることができます。
色々な設計手法を知るだけでも私自身と私が指示するAIエージェントにとってより良いプログラムを書くことにつながるのではないかと考え、本書の読書を開始しました。また、個人的に英語学習をしており、英語かつ設計の勉強もできる書籍も探していました。
おすすめの読み方
本書は英語で書かれているため少しハードルを高く感じる方もいらっしゃると思います。私もグローバル化推進中の企業に属しており、ここ1年の英語学習に対する感度は高い方だと思いますが、それでも未知の洋書を読むのには心理的ハードルがあります。
しかし、本書の場合は非常に読み進めやすい環境が整っています。
twadaさん・iwashiさんのわかりやすい解説音声
もう2年ほど前のエピソードになっていますが、以下の3エピソードは fukabori.fm で公開されているメッセージです。
また、パーソナリティのiwashiさんが別途ブログを書いてくださっています。
これらを先に見る・聞くだけでも、本書の概要や「例えばこの考え方はこういう前提だとどうだろう？」といったありがたい先人のアドバイスを頭にいれることができます。
個人的に英語書籍や日本語で書かれた漫画の英語版による多読学習を開始したのですが、自分の好きなコンテンツや世界観がわかっているコンテンツの読書は負担が非常に軽くなると実感しています。
何気なくtwadaさんたちの「ここでいう interface は Java言語など特有の機能ではなく、関数や変数などの意味合いで」と説明してくれる言葉を頭に入れておくだけでも、読書中の負担を大きく減らしてくれました。もちろん本書でも多々出てくる考え方である「Deep Module」といった考え方もわかりやすく解説してくれますので、ぜひ聞いておくことをおすすめします。
個人的な感想・特に心に残ったポイント
ここからは個人的な読書後の感想や心に残ったポイントを記載します。まず、全体的な感想は以下の通りです。
- この書籍は複雑性に焦点を当て、複雑性を増やさない・対処するための考え方が掲載されている
- 今まで当たり前のように感じていた「極力関数やクラスを小さくする」という考え方の他に「モジュールの深さ」という考え方をインプットすることができた
- 行数の少なさなどにこだわりすぎず、他の観点でも適切な設計を考える（それらが不要と言っているわけではありません）
- ソフトウェアを使う人や読む人にとってわかりやすいかという観点で設計をする
- その考え方がモジュールの深さやコメントの量・書くべき場所などの話にもつながっている
- また筆者は既存の考えや書籍について否定的な意見を述べられることもありましたが、例えば「進行中の開発であれば、いきなり自分の考えだけでそれを崩さない。一貫性というのは強く複雑性に影響している」ということをお話しするなど、何もかもを否定するような形では断じてないと感じました
- コードの読み手や使い手にとって読みやすい・わかりやすいコードにする、といった何度も出てくる考え方が根底にあるのだと思っています
もちろん「これはSDETの帽子を被った私としては少し違和感がある」といった部分もありましたが、全体的に普段意識できていないポイントばかりで読んで非常によかったです。
以下では特に心に残ったポイントに絞って、概要や私の理解を記載しています。
Strategic（戦略的）なアプローチで設計をする
Chapter.3 Working Code Isn’t Enough(Strategic vs. Tactical Programming) という章において、早く動く機能を作成することにフォーカスしすぎた設計方針ではなく、戦略的に長期的に使いやすく複雑性がない設計をしていこうということが書かれていると思います。
なお、終盤の章でも似たようなことが書かれており、私自身疑問や懐疑的な時につける黄色のマーカーで「わかってるけど、それを実現するためにはソフトウェアエンジニアリング以外の力が必要すぎるのでは」といったメモも正直に残しています。
とはいえ重要だと感じたのは、そのような戦略的なアプローチで設計をするとどの程度の期間で生産性とメンテナンス容易性が交差する（元がとれるか）といったことに関して、「6-18 months」と示されています。
個人的にはAIツールやサービスの進化により、もっと早まっていると感じており以下の Podcast エピソードにおいても数日レベルでは？という見解が示されていて、なおさら良い設計を学んでおくことの重要性を噛み締めました。
モジュールの深さ
Chapter.4 Modules Should Be Deep ではモジュールを設計する際に深さを意識するべきだということが書かれています。
冒頭でも紹介された以下のブログにて「深いとは？」ということを解説してくださっています。
私自身のこれまでの経験としてクラスや関数をとにかく小さくすることに目がいきすぎて、あまり機能を持たない小さなクラスを作りすぎていた失敗もありましたので、面白い観点だと感じました。
確かにユニットテストという観点では書きやすかったのですが、 export されたクラスが読む側にとってのインターフェースを増やしているという観点が足りていませんでしたので、極力インターフェースを狭く機能を実装するという考え方が勉強になりました。
大部分を省いていますが、この書籍では「使う側や読む側が知るべきことのないことを少なくしよう。隠蔽しよう」といったことが繰り返し出てきて、「理解しやすいコードとは読み手や使い手の視点で書かれるもので、書く側の都合ではない」といった考え方からきているのだろうと感じました。この考えがこの書籍の一つの根幹ではないかと感じています。
コメントに対する考え方
Chapter.13 Comments Should Describe Things that Aren’t Obvious from the Code など複数のチャプターでコメントに対する考え方や、どこにどのような情報を書くべきかということが記載されています。本書は（私にとっては）抽象的な書き方が多かったですが、このコメント回りに関しては具体的なコードベースでの例が多く書かれていると感じました。
インターフェースに対するコメントの書き方、実装に対するコメントの書き方や場所なども非常に勉強になりましたが、個人的に良いなと感じたのは 15.2 Write the comments first という章に書かれていた内容です。
筆者のプログラミングにおけるコメントの使い方で、以下のように書かれていました。
- 新しいクラスを書く前にまずインターフェースに関するコメントを書く
- 最も重要な public 関数やシグニチャに対するインターフェースコメントを書く。この時中身はまだ書かない。
- 基本的な構造が正しいだろうと思うまでコメントを書いたり修正することを繰り返す
- 重要なインスタンス変数などに関してコメントや宣言を書く
- ここまできてようやくメソッドの中身を書き始める
- 書きながら新たな関数や変数が必要だと気づいたら、また適切なコメントを先に書いて実装をくり返す
Agentic Code を行ってAIに実装を行わせる場合にも、コメント駆動で先に全体のインターフェースを書かせておき、実装を テスト駆動開発で行ってもらうやり方はかなり良いのでは？と考えました。（なお本書の作者はTDDについて否定寄りなご意見もかかれています）
今後作業をAIに任せることが非常に大きくなることを鑑み、このやり方で設計の概要や実際の振る舞いを理解しながら開発を進める手法はぜひ今度試してみようと思います。
まとめ
- A Philosophy of Software Design という洋書を読了しました
- twadaさんやiwashiさんなどのPodcastやブログに先に目を通しておくことで、かなり快適に読書を進めることができました
- どの書籍にもいえることですが「この文脈では違うんじゃない？」という意見がでてくるので、そういう考え方でコメントを残していくやり方が私にとってはよかったです
以上、最後まで読んでいただきありがとうございました。
Views: 0
