A Philosophy of Software Design を読みました

友人からのすすめで "A Philosophy of Software Design" という本を読んだ。

本書は「ソフトウェアの複雑性」というテーマを軸に、筆者の経験からそれに対する向き合い方と明瞭なソフトウェアをデザインするためのノウハウについて書かれている。

ここで言う複雑性とは、システムの理解や変更を大変にするソフトウェアシステムの構造に関連するすべてのもの、と述べられているが、大きく次の3つによって引き起こされるという。

Change amplification
- 単純な変更なのに修正箇所が膨大になる
Cognitive load
- 認知負荷が高まってしまう
Unknown unknowns
- 何を変更すればいいのかわからない

いわゆるレガシーシステムを保守・運用している身としては、まさに言い得て妙という感じだ。当時の担当者の離職や契約終了によりブラックボックスと化してしまっているシステムも少なくなく、複雑性の塊に違いないだろう。

これらを生み出す根本的な原因は「依存性」と「曖昧さ」であり、いかに減らしていくかを考える必要がある。本書はモジュールやクラスといったマクロな話題から始まり、コメント・変数名など明日使えるテクニックにいたるまで書かれているため、ソフトウェア開発の様々なプロセスで「複雑性」についての気づきを与えてくれる。

私はデザインパターンについては詳しくないので前半部はそこまで納得感はなかったが、後半部、特にソースコードコメントに関しては、自分がぼんやりと描いていた「こうするといいんじゃないかな」が言語化されており、なんだかすごく親近感が湧いた。

1つ抜粋すると

コメントは先に書こう
- 最初に書くことで文書化が設計プロセスの一部になる
- 設計上の重要な問題が記録される
- コメントが長くなってしまうようなメソッドや変数は適切な抽象化が行われていない証拠。それを早期に発見できる
- 早期に設計上の問題を発見できるので、結果としてコストが減らせる

といった具合だ。

実は以前、未経験の新入社員がチームに配属された最初の開発で似たようなことをやった記憶がある。当時は「コメント同好会」などと言ってコメントを書くハードルを下げていたのも思い出した。実装としてはバッチ処理を1つ作るくらいの小規模なものだったが、第1ステップとしてモブプロチックに開発メンバー全員でソースファイルにコメントを書く、ということをやったのだ。そのときは新入社員を置いてきぼりにしないくらいの目的だったが、これによって抽象化が行われ