Clean Architecture の商品レビュー

ロバート・C.マーチン(著者),角征典(訳者),高木正弘(訳者)

2019/06/23

コード片と文章で説明されているので、ある程度プログラマとしての経験がないと理解は難しいだろうなという印象。
デザインパターンが前提知識になっているんですが、あんな23個も覚える必要なかったな、、と遠い目で思います。
JJUGで聞いたクリーンアーキテクチャの実践は、やっぱり面倒だと思うし、規模にもよるけど、保守性を担保するのにここまでやる必要あるのかなと、やや懐疑的。
とりあえずコードは書けるようになったけど、きれいに書くにはどうしたら良いか迷ってる人にはオススメかも。

以下、気になったところの引用。

p34 ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

p119 多くのアプリケーションにおいて、再利用性よりも保守性のほうが重要だ。

p244 ソフトウェアを構築する3つの活動
1.まずは動作させる。動作しなければ、仕事にならない。
2.それから、正しくする。あなたやほかの人たちが理解できるようにコードをリファクタリングして、ニーズの変化や理解の向上のためにコードを進化させていく。
3.それからら高速化する。「必要とされる」パフォーマンスのために、コードをリファクタリングする。

p259 アーキテクチャの観点では、データベースはエンティティではない。

2019/02/10

印象に残ったことメモ

- ソフトウェアアーキテクチャの目的は、「求められるシステムを構築、保守するために必要な人材を最小限に抑えること」である。

- 設計の品質は労力で計測できる。必要な労力が少なく、ライフタイム全体で低く保たれているならば、その設計は優れている。逆に、リリースごとに労力が増えるなら、その設計は優れていない。

- 崩壊したコードを書く方がクリーンなコードを書くより常に遅い。よくある、「あとでクリーンにすればいいよ。先に市場に出さなければ」これは、リリースごとの負担が増えていき、開発スピードが鈍化していき、先にクリーンにしているコードよりも後に市場に出る結果となることが経験的に多いそう。

- オブジェクト指向とは、「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」そのために依存関係逆転の原則を使う。

- 言語パラダイムが進むにつれて進化しているのは、何をすべきではないか、である。

- 安定度/抽象度等価の原則「参照される数が多いモジュールほど抽象的に。参照される可能性がなければ無駄に抽象的にしない。」

- 選択肢を多く残す
上位方針（ビジネスルール、ビジネスロジック）から決める
詳細の決定はできるだけ遅延させる。選択肢を残す（データベース、フレームワーク、ウェブサーバー、GUI、IOなどは変化しやすい）

- ビジネスルール
これがエンティティオブジェクトとなる。エンティティは特定のフレームワークには依存せず、何にも依存しない Plain Old Data で作るべき

- ハードに依存しないコードを書く
レイヤ
　- ソフトウェア　　：ハードウェアに依存しないコード
　- ファームウェア　：ハードウェアに依存するコード
　- ハードウェア

- 組み込み開発では、できるだけファームウェアを書かない。ソフトウェアを書いて、できる限り寿命を延ばす。ハードウェアは進化していく。変化しやすいものに依存していると、そのコードも修正が必要。ハードウェアの変化に合わせてファームウェアは変化していくが、ソフトウェアは変化しない。

2018/10/22

半分も理解できた気がしないので評価は保留。
この本は基本的には業務アプリケーション向けで、小さなサービスならここまで考えるコスト賄えなさそう。

2018/09/16

クリーンアーキテクチャに限らず、アーキテクチャについての幅広い知見が詰まった一冊です。
もっと若いときに読んでおきたかった本です。
一方で、ある程度現実のソフトウェア開発を経験してからでないと理解しづらいかもしれません。

ところどころ読みづらい部分、やや冗長な部分があるので星マイナス1です。