A Philosophy of Software Design を読んだ
A Philosophy of Software Design を読みました
全体の感想
賛否あるだろうなという内容もちらほらあったと思うが、自分はほとんどの章について同意だった。
小さなクラスに分けまくるのを推奨していない印象で、あくまでインタフェースが重要で、クラス設計やメソッド設計・コマンド実行時のオプション設計など、いずれの場合も、利用者から情報を適切に隠蔽すること・シンプルに明白にすること、という方針が良いと思った。
特に心に残ったところ
3 Working Code isn't Enough
- 動くコードだけでは十分ではない
- Tactical Programming (戦術的プログラミング)
- できるだけ早く機能を動作させることに焦点を当てた考え方
- Strategic Programming (戦略的プログラミング)
- 今の仕事を早く終わらせるために不必要に複雑なものを導入してはいけない
- 戦術的トルネード(a tactical tornado)
- 他の人より遥かに早くコードを書くが、戦術的な方法で仕事をするため、破壊の軌跡を残す
- 戦術的トルネードが残した混乱を一掃する本当のヒーローであるエンジニアは、戦術的トルネードよりも進捗が遅く見える
- 最適なアプローチは、継続的にたくさんの小さな投資をすること
- 全開発時間の10〜20％程度を投資に費やすことがお勧め
新規ではなく機能追加の際、特に小さい変更だと戦術的プログラミングで妥協することが実際ちょくちょくある。問題が大きくなってきてからリファクタリングするのは大変で、後できれいにしきれないことも実際良くある。 普段から小さい投資を行い、それをコントロールできる知識や余裕を持つ必要があるなと再認識した。
4 Modules Should Be Deep
- Deep Modules
- 強力な機能を提供しながらも、シンプルなインターフェースを持つ
- Shallow Module
- 提供する機能に対してインターフェイスが複雑なもの
- クラスや他のモジュールを設計する際の最も重要な問題は、それらを深くすること
- 一般的なユースケースのためのシンプルなインターフェースを持ち、なおかつ重要な機能を提供すること
- これによって、クラスや他のモジュールに隠蔽される複雑な部分を最大化することができる
Deep / Shallow という言い分けがとてもいいなと思った。
実際の例がこのあとも繰り返し出てくるので、イメージを持ちやすい。 （が、本を読んでいない人にうまく説明できる自信はないので、ぜひ読んでほしい）
19 Software Trends
- Agile development
特にアジャイルのほうで、小さくリリースできる単位でサイクルを回していくのが正義 みたいな書籍・記事が多い印象で、ちょっと違和感があったのだが、なんとなく言語化されて腑に落ちた。 うまくやらないと戦術的プログラミングに寄りすぎるんだなと思った。
まとめ
設計スキルを上げたいと言われると、これはでは色んなパターンを知ってみたら？という返し（つかってるFWの機能をもっと知る・他の人の書いた機能を読んでみる・OSSを読んでみる）になっていて、うまく答えられてる自信がなかったのだが、今後は自信を持ってこの本をおすすめしていきたい。
