エンジニアの今井です。
最近、海外で高い評価を得ている「A Philosophy of Software Design」を読みました。

www.amazon.co.jp/dp/B09B8LFKQL

「A Philosophy of Software Design」は直訳するとシステム設計の哲学でしょうか？ 本書はシステム設計の問題は複雑性だと捉え、複雑性への対処法を示しています。コードの実例も豊富で分かりやすいです。

今回はその中でも特に印象深かった3つの内容を紹介します！

システムの本質的な難しさはシステムが複雑なことです。
システムが複雑になっていくと、次のような事例が発生していきます。皆さんもいくつかは心当たりがあるのではないでしょうか？
・コードの一部の動作を理解できない
・小さな改良に大きな労力がかかる
・改修範囲が不明瞭でわからない
・デグレなしで改修できない

複雑性は形式的に次の式で表せます。この式は計測することは難しいですが、複雑さとは何かを理解するには役立ちます。

この式から次のことが分かります。
・システム全体の複雑さはシステム各部の問題が合わさったもの
・改修がなければその箇所の複雑さは問題ない
・改修が多いところは、少ない複雑さでも問題になりえる

上でも書きましたが、複雑さによって次の悪いことが起きます。
・変更の増加 : ひとつの変更に対して、変更すべき箇所が増える
・認知的負荷の増加 : 改修のための必要となる知識が増えること
・未知の未知の増加 : 改修のために何を知らなければいけないかがそもそもわからないこと

このような複雑さは次のことが原因で現れます。
・依存性 : 改修したいコードが別のコードに依存していること
・不明瞭さ : 重要な情報が何かわからないこと。例えば、処理の順番や変数の単位のこと

システムの複雑性を減らすには、依存性や不明瞭さを少なくし、複雑さを減らすことが大事です。

複雑さを減らすには、いくつかのコードをひとまとめにしたモジュールにすることが有効です。
モジュールの機能はモジュールのインターフェースをとおして提供されます。インターフェースのおかげで、モジュール利用者はモジュールの実装を知らなくても良いから複雑性が減ります。

ここから、モジュールのインターフェースに対してモジュールの機能が大きいと複雑性が減っていると言えるでしょう。
このようにインターフェースの単純さに比べて機能が大きいモジュールを深いモジュールと呼びます。
深いモジュールは複雑性を減らすのに役立ちます。

逆にインターフェースに対して機能が少ないモジュールもあり得ます。このようなモジュールは浅いと言えます。
浅いモジュールはモジュールのインターフェース分知識が要求されるのに、機能が少ないので複雑性の低減には深いモジュールよりも役立ちません。

複雑性を減らすため、モジュールは深くしていきましょう。

適切に書かれたコメントは、コードの内容をを抽象化し、複雑性を減らすことに役立ちます。
例えば、インターフェースに書かれたコメントは引数やメソッドの意味、設計の根拠、戻り値がどういうときにどういう値が返ってくるかなどの内容はコメントで書けます。
一方、変数の単なる直訳や「aにbを代入」のようなコードを読めばわかることは、実装を抽象化していないため複雑性の低減に役立ちません。

良いコメントとは、コードからではわからないことを書いてあるものです。

コメントを実装よりも後で書こうとしても、コメントをちゃんと書かなかったり設計の根拠を忘れがちです。
これを避けるために、先にコメントを書くと良いです。
コメントを先に書くことはコメントの漏れを防ぐ以外にも大きなメリットがあります。

実装がないうちからコメントを書こうとすると、インターフェースや設計について考えさせられます。
例えば、コメントが複雑で難しいのであれば、設計に不備があるかもしれません。
コメントを先に書くと実装よりも早く設計の問題に気づけます。

・複雑性は何よって発生し、どのような影響を与えるかわかった
・利用者にとって複雑性を減らすモジュールのインターフェースとは何かわかった
・TDDのように、コメントをうまく活用すれば設計の問題を事前に調べるツールになる

A Philosophy of Software Designはページ数が多いですが、大変ためになる本でした。情報がモジュール外に漏れる情報漏洩など、今回は紹介しきれなかったこともたくさん書かれています！
もしも興味を持った方がいたら、「A Philosophy of Software Design」を読んでみてください！