Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。

Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。

機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agility は性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキテクチャで急成長に備えよ。そう訴えて勢いづく BDUF Microservices 勢を威嚇すべく Sacrificial Architecture は生まれた。でも行き過ぎた一般化に拡大解釈が加わり技術的負債を自己破産する言い訳として流布してしまった。誤解されても無理はない名前だ。焦って口が滑ったな。

性能に対する法外な期待に応えるには書き直しが必要かもしれない。これは妥当な意見に思える。それに別の見方もできる: 性能が追いつかないほどビジネスが急成長しているときは、勢いに乗って書き直しても元がとれる。性能不足は好調さのあらわれ。無理をしてでもこの勢いを逃したくない。機会損失が書き直しの危険を上塗りする。

一方、古き良きダメな書き直しは機能の変化や複雑化に音を上げておこる。この書き直しは何がまずいか。

別の角度から眺める。ソフトウェアの方向性を大きく変えたいとき、あるいは機能をやたらと追加したいとき、だいたいビジネスは失速している。行き詰まりを打破しようと方向転換や守備範囲の拡大を図っている。この投機的な場面で更に書き直しの博打を打つのは雪解けの薄氷で踊るようなもの。危険に見合う期待値がない。

Martin Fowler はこう言うべきだった: ソフトウェアは確率的に sacrificial である。どんなソフトウェアも連続した打ち手では乗り切れない急激な変化に襲われる可能性を孕んでいる。特に成功したインターネット企業では成長という大波が性能上の限界にコードを打ち付ける。けれど波の狭間に新大陸の影が見えていたら? 賭けに出よう。その愛するコードを生贄に…

こうして犠牲となってしまうコードはある。でもそのためのアーキテクチャなんてない。やっぱり失言だな。

拡大解釈された Sacrificial Architecture もけっこう人気がある: スピードのためにひどいコードを書き、うまくいって長期的展望がもてた頃合いでゴミを捨て書き直す。このアイデアは妥当か。うまくいくこともあるだろう。性能だけが書き直しを正当化するとは言わない。でも Martin Fowler 名義でそれを語るのはやめてあげたい。傷に塩塗るみたいで気の毒。例に挙げるのも別の何かにした方がいい。個人的には Windows NT あたりを推したい。人生を書き換えるアーキテクチャとでも呼ぼう。

書きたいことは別にあったけど長くなったので一旦おしまい。