2020年4月17日、金曜日。結局「城之内死す」まで見てた。これも「何度見ても笑っちゃう」映像のひとつかも。フリが効いてるんだよな。

VSCodeのExtensionの管理をちゃんとやろうと思って調べてみた。 ~/.vscode/extensionsに拡張ファイルたちが入っていることがわかった。ただファイル容量が大きくなってしまうので、一覧を管理したいのが本音。

あわせてsettings.jsonもちょっと手入れ。Pythonをもうすこし極める気になったので明日もうすこしやってみようと思う。

食洗機を買ったことで、食洗機に依存した食器を揃えたほうがいいかなと計画していた。食洗機は安定度が高いので、食器や生活を食洗機に依存させるべきなんだろう。

というかもしかして生活全般を依存制御すべきなのでは。なんてちょっとダーティーなエンジニアすぎるかも。だけれど「私」について「安定している（依存される、変更できない）」とするか「安定していない（依存する、変わりやすい）」とするかは、とても哲学的というか、意外と人生教訓みたいになっちゃったな。「依存することは固着ではなくて、むしろ自分の可能性をどんどん変えられるチャンスなんだ」みたいな。自己啓発本が一冊かけそう。

---ひきつづき、『clean architecture 達人に学ぶソフトウェアの構造と設計』の第Ⅴ部。

• 第15章: アーキテクチャとは？

• アーキテクチャの「形状」の目的は、 ソフトウェアシステムの適切な動作ではなく 、開発・デプロイ・運用・保守を容易にすることである* それらを容易にするための戦略は、 できるだけ長い期間、できるだけ多く選択肢を残すこと である* 「残すべき選択肢」とは、重要でない詳細である* （開発初期の）データベースシステム* （開発初期の）ウェブサーバー（ウェブ経由で配信するかも決めなくていい）

• （開発初期の）RESTなど、外の世界に対するインターフェース* （開発初期の）DIフレームワーク* 決定を遅延させることで、システムを適切につくるための情報が数多く手に入る* 優れたアーキテクトは、「方針」と「詳細」を慎重に区別して、詳細の決定を保留できるように方針をデザインする* 第16章: 独立性* ソースコードを変更から保護するために、システムの切り離し方式（の選択肢）をシステムの成長にあわせて検討しなければいけない* レイヤーやユースケースを切り離す方法として、次のようなレベルがある* ソースレベル: モジュールの変更が他モジュールの再コンパイルにつながらないよう、モジュール間の依存性を管理* デプロイレベル: モジュールの変更が他モジュールの再ビルドにつながらないよう、デプロイ可能な単位の依存性を管理* サービスレベル: 依存性をデータ構造のレベルにまで下げて、ネットワークパケットだけで通信する* たとえば最初からサービスレベルで切り離すこともできるが、そのためのリソースは高くつく* サービスを「作れそう」なところまで切り離すのが良いのではないだろうか* 第17章:バウンダリー：境界線を引く* アーキテクトはシステムの構築・運用リソースを最小限に抑えるため、早すぎる決定との「結合」を防がなければならない。

• 早すぎる決定を延期・保留するには、「境界線を引く」ことだ。

• 境界線は「重要なもの」と「重要でないもの」の間に引く* 入出力はモデル・ビジネスルールにとって「重要でない」

• 境界線を引くためには、システムをコンポーネントに分割し、必要な機能が含まれるコアなコンポーネント以外をプラグインにする* 依存関係逆転の原則（DIP）、安定度・抽象度等価の原則（SAP）の適用* 第18章:境界の解剖学* モノリシックな実行ファイルであれば、下位レベルから上位レベルへ依存するように分割する* 最も強い境界はサービスであり、あらゆる通信はネットワークを介して行われる* （感想）通信の情報量は境界の強さと相関関係にある* 第19章:レベル* レベルとは「入出力からの距離」である* 入出力を管理する方針はレベルが最も低くなる* 上位レベルの方針は、変更の頻度は低いが、変更の理由は重要となる* 下位レベルの方針は、変更の頻度は高いが、（緊急性は高いものの）変更の理由は重要でないだんだん内容が大きく、抽象的になっていくので理解するのになかなか時間がかかる。クリーンアーキテクチャを示す同心円の図がシェアされて終わり、というのが本書のよくある読まれ方なのだが、精読すると「選択の保留」がもっとも重要であることにあらためて気づく（このあともっと重要なものが出たりして）。

読みながら感じたのは、よく「設計に”失敗した”からプロダクト開発も失敗した」と聞くけど、実際は「設計を”続けなかった”からプロダクト開発が失敗した」というのが正しいのかもしれない。言い換えれば「レジェンドコード」（下記参照）が生まれるのは当然であり、これをレジェンドにしない試みをプロダクトが存続するかぎり続ける必要があるのかなと思った。