確率的に犠牲的 - steps to phantasien
Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。 Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。 機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキ
Takuto Wada on Twitter: "既存システムをサブシステム分割して段階的/定期的に刷新し続ける戦略について議論と説明をするときに、伊勢神宮の式年遷宮をメタファとして使うと通りが良くて助かる。伊勢神宮はアーキテクチャスタイルのリファレンスモデルであり、時を超えるためのパタンランゲージでもあるのではないか。"
既存システムをサブシステム分割して段階的/定期的に刷新し続ける戦略について議論と説明をするときに、伊勢神宮の式年遷宮をメタファとして使うと通りが良くて助かる。伊勢神宮はアーキテクチャスタイルのリファレンスモデルであり、時を超えるためのパタンランゲージでもあるのではないか。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
