Clean Architecture 達人に学ぶソフトウェアの構造と設計
Robrt C. Martin, 角征典, 高木正弘 著
ISBN-13: 978-4048930659
第2章 2つの価値のお話
この章では、ソフトウェアの振る舞い(機能)と比較して構造(アーキテクチャ)の重要性を述べている。
本章では以下の単語が同義だと僕は認識している
構造 = アーキテクチャ振る舞い = 機能
keyword
振る舞いと構造
- ソフトウェアシステムが提供する価値には「振る舞い」と「構造」がある
振る舞い
- ここでの「振る舞い」とは、ソフトウェアの機能と同義
- バグがあればそれを修正する。それだけがプログラマの仕事ではない
構造(アーキテクチャ)
- 「ソフトウェア」…マシンの振る舞いを簡単に変更できる(ソフト) 製品(ウェア)
- 「ハードウェア」…振る舞いを簡単に変更したくない製品
形状にとらわれないアーキテクチャを選択すべき
- 「四角い」ペグを「丸い」穴に打ち込むようなことがあってはならない
(ソフトウェアの)大きな価値
機能よりもアーキテクチャが大切
- 完璧に動作するが変更できないプログラムはいずれ役に立たなくなる
- 動作しないが変更が簡単なプログラムは、要件が変更されても修正が容易なので、今後も役立つ
ビジネスマネージャは将来の柔軟性よりも現在の機能性を重要だと回答する
- とはいえ、開発者が変更を求められ膨大なコストを見積もると、ビジネスマネージャは激怒するだろう
アイゼンハワーのマトリックス
重要 | 重要 緊急 | 緊急ではない -----------+----------- 重要ではない | 重要ではない 緊急 | 緊急ではない
私には緊急と重要の２種類の問題がある。緊急と重要は違う。重要なことが緊急になるわけではない。
- 緊急かつ重要
- 緊急ではないが重要
- 緊急だが重要ではない
- 緊急でも重要でもない
コードのアーキテクチャは1と2
コードの振る舞いは1と3
よくやる間違いは3を1にすること。「緊急だが重要ではない」を「緊急かつ重要」
- システムの重要ではないことを優先し、システムの重要なアーキテクチャを無視することに繋がる
ソフトウェア開発者のジレンマは、ビジネスマネージャがアーキテクチャの重要性を評価できないこと
- ソフトウェア開発チームには、機能の緊急性よりもアーキテクチャの重要性を強く主張する責任が求められる
アーキテクチャの戦い
マネジメントチーム、マーケティングチーム、セールスチームがそれぞれ企業にとって最善と思えるものを求めて闘争する
- 開発チームも同じくね
- その状態が許されているようなら、ソフトウェア開発チーム自らが必要とするもののために、懸命に戦わなかったということ
感想
「振る舞い」を「機能」と述べたり、「構造」を「アーキテクチャ」と述べたりしている。 同じ言い回しで飽きないようにしているんだろうか。 それとも別の意味で言っているのか。 翻訳元でもstructure, architectureって書いてあんのかな。 わかんね。