blog.syfm

徒然なるままに考えていることなどを書いていくブログ

A Philosophy of Software Design を読んだ

A Philosophy of Software Design

A Philosophy of Software Design

170 ページくらいの洋書で、ソフトウェアの Complexity (複雑さ) について扱っている。洋書ではあるけど、難しい表現はあまりなく読みやすかった。

この本の冒頭で、Complexity を「ソフトウェアシステムを理解しづらくさせたり、変更させにくくする、システムの構造に関連するすべての要素」と定義し、それによって引き起こされる問題を述べている。
それ以降の章では、いかにして Complexity を減らすかというところにフォーカスし、モジュールの設計やレイヤーごとの抽象度、エラーの定義とハンドリング、コメントの種類と記述すべき場所など、さまざまな視点から見た手法や考え方が紹介されている。
どの章も興味深い内容だったけど、特に以下の章が良かった。

  • 第 4 章「Modules Should Be Deep」
  • 第 10 章「Define Errors Out Of Existence」
  • 第 13 章「Comments Should Describe Things that Aren't Obvious from the Code」

第 4 章「Modules Should Be Deep」には「deep module」という必要最小限の公開インターフェース (API) のみで多くの機能を提供できるようなモジュール設計の考え方が登場する。これを守ったモジュールは恐らく SOLID 原則を守ったモジュールと同様の特徴を持つと思うけど、モジュールの質を「deep」かどうかで測るという新しい視点は非常にわかりやすく、面白いと思った。

第 10 章の「Define Errors Out Of Existence」での、「モジュールの使用者が知らなくてはいけない例外やエラーは、そのインターフェースの仕様の一部 (= 仕様が増えるほど Complexity も増える)」という考え方が非常に良かった。さらに、この章では、その考え方に基づいて、エラーとしてモジュールの利用者へ投げないエラーを定義したり、いくつかのエラーを集約する手法が紹介されていた。

自分が普段よく使っている Go の標準ライブラリもこういった思想に基づいて作られているので、改めてよく設計されているなぁと感じた。

第 13 章の「Comments Should Describe Things that Aren't Obvious from the Code」は個人的に一番良かった章だった。 この章ではコメントの種類を以下の 4 つに分類し、適切な箇所に適切な種類のコメントをすべきだと主張していた。

  • インターフェースコメント: モジュールを利用するにあたって、そのインターフェースの振る舞い、引数や戻り値、副作用や返す可能性のあるエラーなどの記述
  • データ構造メンバコメント: クラスのフィールド変数や、静的変数に対するコメント
  • 実装コメント: メソッドや関数内に書くコメントで、それらのコードがどう動作するかの記述
  • クロスモジュールコメント: モジュールを跨ぐ依存に関する記述

モジュールの利用者に近い (より上位な) 種類のコメントでは、どういう振る舞いをするか (how) を記述する。その内部動作を抽象化したモジュールの仕様を記述し、実装をモジュール使用者から隠蔽する。 より実装に近い (下位な) 種類のコメントでは、なにをしているか・なぜそうしているか (what / why) を記述する。コメントの読み手がコードの挙動を理解できるように正確な記述を行う。

最近は、Go ソフトウェアを書くときにかなりの頻度で作成しているパッケージの GoDoc ドキュメントを見ることで、理解しやすい記述かを客観的に確かめたりしていた。そのため、この章で紹介されていたコメントの書き方は非常に参考になった。

この本の様な、即座に自身の開発スタイルやコードレビューに適用できる内容を扱っている本は今まであまりなかったため全体的に新鮮だった。もうちょっと戦術寄りな本だとリーダブルコードが近いと思った。
冒頭でも言ったとおり、そんなにボリュームが大きくなく読みやすい英文なので洋書を読んでみたいけどハードルが高い…と感じている人も是非。