こういう本好きなのと，話題になっていたので買ってみて真面目に読んでみています．
話題になってて気になってポチった本が届いた。ソフトウェアデザインをしていてよく思う迷いどころに対する解決策が載ってそう🙂 pic.twitter.com/CCUdzvB6wh
— yuki (@helloyuk13) December 2, 2018
読みながら感想等々書いていくと頭に残りそうなのでやってみます．ただあんまり要約すると，それはそれでネタバレ感がすごいので続きは本書をご購入の上ご覧くださいということでお願いします．いい本です．
4章くらいまで読んだんですが，一旦1〜3章がひとつの意味上の区切りとしてピッタリそうなので，ここまでの3つをまとめておきます．
A Philosophy of Software Design
- メディア: ペーパーバック
- この商品を含むブログを見る
1章
本の導入なので割愛．英語の本って1章のイントロダクションで丁寧に本の全体像を解説してるので読みやすいですよね．
2章
ここで Complexity という本書のコアとなる概念が登場してきます．どう翻訳するのがベストかはわかりませんが，Complexity = 複雑性と翻訳させてください．
本書では，複雑性は次のように定義されます．
Complexity is anything related to the structure of software system that makes it hard to understand and modify the system.
「複雑性とは，システムを理解・変更することを困難にするソフトウェアシステムの構造に関連するものです」とのことです．要するに，コードは読めないし，コードがスパゲッティで修正が難しくなっていることを複雑性と呼んでいる，くらいの理解で読みすすめていくことにします．
後半で，複雑性の具体的な症例として次の3つが載っていました．
- Change amplification: 変更箇所がめっちゃ増える，くらいの意味だと思います
- Cognitive load: 直訳すると「認知の負荷」っていうことになるんでしょうけど，要するに「コードが読めん，わからん」ということです．
- Unknown unknowns: あるコードを修正する際に，どの条件を満たしたらそのコードを修正しきったかが把握できない状況のことをいうそうです．
ソフトウェアが複雑になる要因が解説されたあと，複雑性は増え続けるんだよという説明がなされて2章は終わりました．
今回の本では，この複雑性という概念が肝になってくることを予感させる章でした．そして，この複雑性をいかに減らしていくかという方針について，本書の残りの部分が割かれている構成になっていそうですね．ソフトウェアデザインの方針は，何を目標にして設定すればよいのか迷いがちで，だからこそ「複雑性の抑制」に焦点を当てたのはとてもいいなと思います．
3章
動くコードを書けばOK，なんじゃなくて，ちゃんとシステム全体を見通したコードを書くようにしようねという話．
用語が2つ投入されているので紹介しておきます．
- Tactical Programming (戦術的プログラミング): 動けば OK というプログラミングスタイル *1．
- Strategic Programming (戦略的プログラミング): working code isn't enough (コードは動くだけじゃダメだ)．長期的な視野をもって，よいソフトウェアデザインを追求していこうというプログラミングスタイル．
Strategic Programming をしようね，という話です．せやな．あとは，Strategic Programming への投資効果について書かれています．
Strategic Programming する上ではマインドセットも必要とのことです．それはそうですね．Strategic Programming を一番効率よく推し進める方法は，エンジニアみんなでちょっとずついいデザインになるようにコツコツ投資することです．
ここまでで，本書で重要視することがコンパクトにまとめられていました．4章以降は具体的にどのようにしたら，複雑性を抑制でき，戦略的プログラミングをできるのだろうか？という話が書いてあるように見えます．読み終わったらまた，まとめと感想を書きます．
*1:working code is enough，という対になる文章をあてることもできるでしょう．「戦術的プログラミング」と翻訳するとどうも，「短期的な視野」感が失われる…．
