"A Philosophy of Software Design 2nd Edition" の輪読会に参加した。その際の読書メモを記録として残す。
本は以下。
https://www.amazon.co.jp/dp/B09B8LFKQL/
注意: Kindleで買うと自動的に2nd Editionになるが、ペーパーバックを選ぶと版が指定できないように思うので、紙で読みたい人は注意が必要。
序文
The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it up into pieces that can be solved independently.
Computer Scienceでの一番基礎の問題は、問題の分割。
ソフトウェアデザインはそもそも教えられるのか疑問に思ってた。そこで実際にStanford大のCS190で教えてみた。
自分の経験からくるものを教えてる。すべての原則がわかってるわけではない。
1. Introduction
複雑性にどう対処するか。
大きく２つ方法がある。
- コードを簡潔にする
- カプセル化する - モジュラーデザインと呼ばれる
ソフトウェアは変更しやすいので、建物とか船のような物理的なものとは違うんだけど、それらを作る手法が取り入れられてきた。
ウォーターフォールとか。ソフトウェアだとウォーターフォールはめったにうまく行かない。
その理由：
・ソフトウェアは物理より複雑で完全に設計できないので、初期設計から設計に変更がない手法はと難しい
だからインクリメンタルな手法が使われてる。アジャイル開発とか。
インクリメンタル開発が意味するのは、ソフトウェアデザインには完了がないということ。
この本は２つのゴールを目指す。
- ソフトウェアの複雑性の性質を明らかにする
- 複雑性を小さくする開発手法を伝える
2. The Nature of Complexity
2.1. Complexity defined
Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
複雑性は、開発者の行動と関係してる。
たとえば、めっちゃ複雑な部分があるけど、そこを開発者が修正することがめったにないなら、システム全体として複雑性は低い。
つまり、システム全体の複雑性Cは
C = SUM(Cp * Tp)
Cp = 複雑なコードの箇所の量
Tp = 開発者がその箇所の修正にかける時間
の総和になる。
書き手より読み手のほうが複雑性を感じやすいかも。もし読み手が複雑だなぁと思ったら、それは複雑である。
2.2 Symptoms of complexity
複雑性は３つの兆候がある
-
Change amplification(変更量の増加)
ある機能を変更するときに、色んな所を変更する必要がある -
Cognitive load(認知負荷)
変更するために理解する箇所が多い。
ときどき、コード量が多いほうが、シンプルな場合がある。これは認知負荷を下げるため、シンプルに感じられる。 -
Unknown unknowns:(知らないことを知っていない)
どこを変更すればタスクが終わるかがわからない
webサイトの背景色を変更するときに、１つのcssをいじったら完了とおもいきや、特定ページで個別のcssを当ててたので、開発者はそれを探しにいかないといけない
3つの兆候のうち、unknown...が一番悪い。
知るべきことがあるんだけど、それを知る方法がないから。バグってみないとわからない。
良いデザインのゴールの一つは、"明確に(obvious)” すること。
2.3. Causes of complexity
2つのことが原因で複雑になる。
- dependencies = 依存
- obscurity = 不明瞭さ？
依存はソフトウェアの基本なので、そもそも全部なくすことはできない。
だけど、数を減らし、シンプルに、明瞭にすることはできる。
不明瞭さは、重要な情報が明確にされていないときに起こる。
だいたい不適切なドキュメントによって起こる。これはChapter 13で取り上げる。
だけどデザインの問題でもある。
もし設計がちゃんとして明確であれば、ドキュメントは少なくて済む。