アーキテクチャ

0から作るケースは考えなくていい

プロトタイプが有機的にでかくなる

例外ケース

何もコードない状態でチームを組成して開発を並列化したい場合

コンポーネントの連携だけするプロトタイプとサンプルのスケルトン実装を作ればあとは↓と同じ

システムに変更を加えるときに考えること

真に解決したいこと

今と理想状態の差分

差分をつぶす

フェーズの分割

"理想"を変えるのが良いパターンもある

側面

物理制約

物理的に無理なものは無理

それはそう

限界と目標の倍率が大きいほど抽象化自由度がある

時間・空間

情報・エネルギー・質量

複雑性

単純な物量 (コード量、ドキュメント量、...)

またがってる領域数

失敗した/legacyな抽象化

物理制約

現状仕様

人間の複雑さ (UX)

開発組織の複雑さ

運用プロセス

理解の難しさ

捨てるか抽象化するか

慣性

ほっといたら何も変わらない

が外界は変わるので壊れていく

複雑じゃないものは簡単に変えられる

システム全体

個々人のタスク

タスク並列化可能性

設計的にきれいじゃなくても、実装が速い設計、というのがある

その上で、時系列的にバランスを調整する

技術的負債

適度な汚さ

とかは時系列で初めて発生する概念