友人からのすすめで "A Philosophy of Software Design" という本を読んだ。
本書は「ソフトウェアの複雑性」というテーマを軸に、筆者の経験からそれに対する向き合い方と明瞭なソフトウェアをデザインするためのノウハウについて書かれている。
ここで言う複雑性とは、システムの理解や変更を大変にするソフトウェアシステムの構造に関連するすべてのもの、と述べられているが、大きく次の3つによって引き起こされるという。
- Change amplification
- 単純な変更なのに修正箇所が膨大になる
- Cognitive load
- 認知負荷が高まってしまう
- Unknown unknowns
- 何を変更すればいいのかわからない
いわゆるレガシーシステムを保守・運用している身としては、まさに言い得て妙という感じだ。 当時の担当者の離職や契約終了によりブラックボックスと化してしまっているシステムも少なくなく、複雑性の塊に違いないだろう。
これらを生み出す根本的な原因は「依存性」と「曖昧さ」であり、いかに減らしていくかを考える必要がある。 本書はモジュールやクラスといったマクロな話題から始まり、コメント・変数名など明日使えるテクニックにいたるまで書かれているため、ソフトウェア開発の様々なプロセスで「複雑性」についての気づきを与えてくれる。
私はデザインパターンについては詳しくないので前半部はそこまで納得感はなかったが、後半部、特にソースコードコメントに関しては、自分がぼんやりと描いていた「こうするといいんじゃないかな」が言語化されており、なんだかすごく親近感が湧いた。
1つ抜粋すると
- コメントは先に書こう
- 最初に書くことで文書化が設計プロセスの一部になる
- 設計上の重要な問題が記録される
- コメントが長くなってしまうようなメソッドや変数は適切な抽象化が行われていない証拠。それを早期に発見できる
- 早期に設計上の問題を発見できるので、結果としてコストが減らせる
といった具合だ。
実は以前、未経験の新入社員がチームに配属された最初の開発で似たようなことをやった記憶がある。当時は「コメント同好会」などと言ってコメントを書くハードルを下げていたのも思い出した。実装としてはバッチ処理を1つ作るくらいの小規模なものだったが、第1ステップとしてモブプロチックに開発メンバー全員でソースファイルにコメントを書く、ということをやったのだ。そのときは新入社員を置いてきぼりにしないくらいの目的だったが、これによって抽象化が行われ
- ビジネスロジックはどうなっているか
- どんな戦略で処理を組み立てるか
- 入力と出力はどうなればよいか
といった実装者の暗黙知となっていた部分が伝搬し、新入社員を含めたメンバーの知識を一定のレベルで合わせることができていたんだなと再確認できた。
人によって携わる分野が異なるので、一概に全て正しいといえるものではないと思うが、私のようなレガシーコードや複雑なビジネスロジックに日々向き合っている身としてはとても納得感があり、日々の開発に取り入れようと思う内容だった。
ただ、2023/09/12現在英語版しか出版されていないので、ハードルを感じない方はぜひ読んでみてほしい。
おまけ
本書を読んでいて「あいまいな」という意味の単語がいくつか出てきたが、ニュアンスが微妙に違うらしい。
- vague: 詳細がわからない・十分な情報がないので曖昧
- obscure: 情報はあるが難しい・わかりづらくて曖昧
- ambiguous: 様々に解釈できるので曖昧
