A philosophy of software design 1章 ~ 3章を読んだメモ

A Philosophy of Software Designを読んだので忘備録としてまとめていきます。

Preface

筆者はスタンフォード大学でソフトウェア設計を教えている。その講義で出てきた原則をまとめたのがこの本。

複雑なソフトウェアに対処するアプローチが２つ。

この本のゴールは２つ。

２章は複雑さとはなんぞや？複雑さの原因ってどんなものがあるんだろう？というお話。

ソフトウェアの複雑さとは、修正や理解を難しくするソフトウェアの構造に関係するもの。システムの修正や理解が難しかったら複雑、簡単だったらシンプル。

一部が複雑なシステムでも、その一部がほとんど触れられることがないのであれば、システム全体の複雑さは低い。複雑さはコードを書くよりも読むときに直面する。他の人が見てシンプルだと感じるコードを書くべき。

Change amplification

一見簡単な変更をおこなうために多くのコード修正が必要になるケース。

Cognitive load

開発者がシステムを開発するために理解しなければいけないことが多く、負担になってしまうケース。コードの行が少ない=シンプルとは限らず、cognitive loadを削減するためにコード量が増えたとしても複雑さは軽減できる。

Unknown unknown

システムを変更するためにどこを修正していいかわからない、もしくはどんな情報が必要かわからないケース。3つの兆候の中でunknown unknownが最悪。必要な情報を得る方法や、そもそも問題がなにかもわからない状態。多くの場合、システムを変更した後でバクが出て初めて気づく。

dependencies

あるコードを単体で理解したり修正したりできないこと。変更しようとすると他のコードを知る必要がある状態。完全に無くすことはできないが、依存関係を減らすことでシステム全体をわかりやすくすることができる。

obscurity

一貫性のない名前や誤解しそうな名前など重要な情報が明確になっていないこと。わかりづらさを補完するために、詳細なドキュメントが必要な場合は、設計に問題があるかもしれない。

複雑さは致命的なミスによって生まれるものではなく、小さいわずかな変更の積み重ねで生まれていく。

良いソフトウェアを設計するためのマインドセットのお話。プログラミングにおいて２つのマインドセットがある。

Tactical Programming

機能の実装やバグの改修をなるべく早く終わらせることをゴールとする考え方。時間を気にしてわずかな複雑さやその場しのぎの方法を良しとしてしまったり、良い設計方法を考える時間を取らなかったり、今後の修正を考えずに開発をしてしまうため、良い設計を生むことは難しい。

Strategic Programming

動くコードを優先するのではなく、素晴らしい設計を生み出すことをゴールとする考え方。新しいクラスを作るたびに、お決まりのパターンで書くのではなく、何個か設計案を考えてみて最もシンプルなものを採用してみる。開発メンバー全員の小さな改善の積み重ねがシンプルな設計につながる。