ソフトウェアは複雑である
近年のソフトウェア開発においてソフトウェアは複雑な構造で成り立っている
- コンポーネント
- 関数
- モジュール
- レイヤー
- サービス
- etc
これらはアーキテクチャの設計に多大なる影響を受ける。 結論から述べるのであれば以下の理由がアーキテクチャが大切だと考える理由である
- 最も集中して設計し
- システムの根幹となり
- 物理的に見ることができない
ソフトウェア開発はコーディングだけではなく、OS やブラウザの種類、言語、DB など組み合わせは無限のように存在し、もはや人類が頭だけで理解できる領域は超えている
この複雑さは、ソフトウェア開発において特に顕著に現れる 例えば建物のアーキテクチャを考えるとすると物理的な重力や材料に配慮すること以外に選択肢はそれほどない(とは実際には言い切れないが、たとえで。)
ソフトウェア開発と物理的な構造を持ったものを比較することは本質的には意味はないが、ソフトウェア開発においてもネットワークの帯域や、プロセッサの速度などはパフォーマンスに影響を与える
物理的に見えるものは、コストとパフォーマンスの両方を天秤にかけることになる。潤沢な資金があるならばコストを取れば良いし、そうでないならばパフォーマンスを多少落とすことも検討することになるだろう そういった意味ではアーキテクチャはソフトウェア開発をする上コストに縛られることはない
- 最も集中して設計し
- システムの根幹となり
- 物理的に見ることができない
以上のような特徴を持っているのではないだろうか
イントロダクション
何か動作するだけのソフトウェアなら近年は誰でも開発できるようになっている
一度だけ動かすことと正しく安定的に動かすことは全く異なる
誰もが、自身の経験を振り返ると相互接続が絡み合い（密結合し）、どんな小さな変更でもリスクを伴うような開発をしたことがあるのではないだろうか（僕はある）
アーキテクチャの設計には時間がかかるが、疎かにすると後々それが原因で起こる障害に時間を取られる可能性が高い
- 小さな変更が多数の場所へ副作用を及ぼす可能性
- バグ修正によって生まれるバグ
- 機能追加する前にバグを直さなければならない循環
- 悪循環がもたらす士気の低下
- 顧客の信頼の損失
- 顧客ではなく設計との戦い
少し考えただけでも多くの機会を失う
アーキテクチャの目的
求められるシステムを構築・保守するために必要な人材を最小限に抑えること
文脈は全く違うけど、エンジニアが増えれば良いわけではないという例 https://logmi.jp/tech/articles/322197
余談
個人的にはチーム開発も一種のアーキテクチャとして捉えられるのではないかと思っている
- その意思決定は本当に A さんが参加する意味があるのか
- 密結合すぎて、一つの変更が多くの人や機能への影響を与えていないか
- 特定の interface(情報の入り口)があれば、誰でも期待した情報が得られていますか
仕事でエンジニアがものを作るのは喜んで欲しい人がいるからです
コードを書くことに集中するのではなく、ユーザに喜んでいただけることに集中することができる
これがチーム開発における最高のアーキテクチャだと思う(とても個人的な思想なのでエンジニアによって変わる部分だと思います)
ケーススタディ
以下の図のような場合には明らかにうまくいっていない
開発人数は増えているのにプロダクトの規模が大きくなっていないからである
崩壊のサイン
以下のような兆候はソフトウェア開発の崩壊のサインである
- リリースするたびに開発者の生産性が落ちる
- リリースするたびに開発者全体の総額の給与が上がる
「あとでクリーンにすれば良い。先に市場に出さなければ」
このごまかしは、長期的には遅いけど短期的には速度が上がるという考え方に基づいている。実際には事実誤認である。
事実は短期的にも長期的にもクリーンなコードを書くほうが常に早い
- 一例として TDD
2 つの価値
ソフトウェアはステークホルダーに 2 つの異なる価値を提供する
- 振る舞い
- アーキテクチャ
である。これらは片方が優先されることが多い
振る舞い
エンジニアはソフトウェアの振る舞いのため（要件を満たすよう）にコードを書く
アーキテクチャ
エンジニアはソフトウェアの振る舞いを容易に変更することができるようにアーキテクチャを考える ステークホルダーからすれば同じような仕様を任せているのに、かかる開発コストが大きくなる（できるだけそうならないようにアーキテクチャを考えるのだが）
振る舞いとアーキテクチャの戦い
振る舞い
- 緊急
- 常に重要ではない
アーキテクチャ
- 常に緊急ではない
- 重要
緊急と重要をメトリクス化すると以下のような優先順位をつけることができる
- 緊急かつ重要
- 緊急ではないが重要
- 緊急だが重要ではない
- 緊急でも重要でもない
振る舞いは 1 or 3 になり、アーキテクチャは 1 or 2 となる
ビジネスマネージャーや開発者がよくやる間違いは 3 を 1 へと昇格させてしまうことである
【重要】 ソフトウェア開発者は機能の緊急生よりもアーキテクチャの重要性を強く主張する責任がある