なんとなく続き。(前回)

Martin Fowler が蒸し返すまで、 自分は書き直しについてことさら何か書く気が起きなかった。 どうでもよさは時がたつほど増していった。気分の出処を見直してみたい。

部分的に書き直す

最初の理由は、書き直しがゼロかイチかの大きな判断ではないという納得かもしれない。コードの書き換えには様々な粒度がある。一番小さいのが厳密なリファクタリング。一番大きいのがフルスクラッチの書き直し。その間には様々な大きさの書き直しがある。書き直しの粒度が連続的である以上、どちらか一端を擁護する議論は虚しい。

小さい刻みの変更を積み重ねれば危険を冒さず大きな変更ができる。それがリファクタリングのテネットだ。刻みは小さいほど安全だから、良いプログラマは大きな変更を連続した小さい変更へと噛み砕く。変更の難しさに実力が及ばないと刻みが大きくなり失敗の危険が増す。バグが増えたり納期に遅れたりする。

自分の能力を超えた変更を求められることはある。仕方なく刻みを緩める。とはいえ全開のフルスクラッチまで緩め切ることはない。大半は部分的な、たとえばモジュール単位の、書き直しで事足りる。まず書き換えるモジュールをくくり出すところから始めることもよくある。Microservices だってそんなかんじでプロセスを切り離すでしょ。たぶん。

一見フルスクラッチを避けがたい場面ですら、十分な(あるいは例外的な)能力をもってすれば安全に大きな変更をやりとげられる。Russ Cox の 異言語間 Go コンパイラ移植 はその極端な例。わかりやすい「細かい変更」の集合ではないけれど、変換を通すための小細工を山ほど積み重ねたはず。

反対から見れば、変更の難しさから技量を差し引き足が出た分を危うい資金で補填するのが粒度の大きい書き直しだとも言える。

互換性を諦める

もう一つの理由は、互換性への期待が変わったことだろうか。フルスクラッチな書き直しへの批判は、書き直された新版が旧版と互換性を保つ難しさを論拠の一つにしている。一方で多くのソフトウェアは互換性を捨てながら前に進んでいる。API は deprecate される。刷新された UI からは不人気な機能が姿を消す。ウェブ標準ですら古い API のうち評判が悪かったものを取り下げている。この非互換は書き直しのバグではなく意思決定の結果だ。 意図した互換性の破棄は前もってわかる。だからランダムに壊れるフルスクラッチの非互換よりだいぶマシ。

互換性を損ねると決めた途端、書き直しは楽になる。決めた範囲で互換性を壊しつつ新しい方向に進めばいい。自暴自棄のフルスクラッチに走りたい衝動は遠ざかる。

Windows 10 に載る新しいウェブブラウザのレンダリングエンジン Edge は、古いエンジン Trident をフォークしたものだ。フルスクラッチの書き直しではない。けれどその違いは既に WebKit と Blink より大きいという。Edge は近代的なウェブでの競争力を理由に IE との互換性を捨てると決め、大きな書き直しの扉を開けた。IE の足を引っぱっていたのはひどいコードでなく互換性の鎖だった。

まあコードもひどかったに違いないけれど、それだけが相手ならプログラマの力量でなんとかできる。Microsoft にプログラマ不足の心配はなかろう。

世紀末の悲鳴

書き直しの切り口はいくらでもあるし、必要なら互換性を切り崩してもいい。フルスクラッチでの書き直しを強行する理由を自分はもはや見出せない。けれど 15 年前に Joel Spolsky が書き直しは悪と書いた時、それは人々の心に響いた。なぜか。西暦 2000 年と今は何が違うのか。

槍玉にあげられたソフトウェアの一つは、奇しくもまたウェブブラウザ。Netscape の失敗を Joel は批判した。Netscape はその後 IE に負け AOL に買収されてしまったわけだから、この書き直しを失敗とみなすのは的外れでもない。今だったら「フルスクラッチで書き直しとかあいつら狂ってるな・・・」で終わる話。けれどたしかに 15 年前、フルスクラッチの書き直しはよくある話だった気がする。

書籍 Refactoring の出版が 1999 年。等価書き換え健康パズルのアイデアは今ほど浸透していなかった。コードは少しずつ腐っていくもの。腐敗を遅らせるのがせいぜい。ソフトウェアのリリースも今よりずっと離散的で、オートアップデートなんてなかった。だから仮に少しずつコードを直せても、それを撒いて試すのは難しかった。人々は健全性を取り戻す術をフルスクラッチ以外に持っていなかったのかもしれない。

一方、ソフトウェアの互換性に対する期待は今よりずっと高かった。それはたぶん Microsoft が持ち込んだゲームのルールだった。彼らは互換性のために莫大な工学資本をつぎ込んで高いバーを設けた。ウェブの時代がそれを塗り替えるまで、互換性への期待はソフトウェアの前に立ちふさがっていた。「同じものは壊れない」というユーザの期待が「まったく新しい何か」へと開発者を追い込み、結果として「すっかり壊れた何か」を生み出し破滅を招いた。

15 年前、ソフトウェア開発者は少しずつ直すことを知らず、少しだけ壊すこともできなかった。フルスクラッチの決断は板挟みになった開発者の悲鳴だった。だいぶ単純化してるけど、時代の空気はそんな風だった気がする。

そして今。書き直しは多くの変数を持つ入り組んだトレードオフに姿を変えた。もはやフルスクラッチの書き直しでわざわざ自分の稼ぎ口をふいにするがさつな開発者はそういるまい。Sacrificed Architecture も全てをゼロから書き直せとは言わない。

時代が変わり、書き直しに関する議論はかつての意味を失った。自分の興味も遠のいた。けれどその一方、誰かが書き直しについて話すのを聞くと私は落ち着かない気持ちになる。意味がないのに落ち着かない。この矛盾がどこから来るのかと考える。一つの理由は、私がまだ時代の変化を自分のものにできていないからかもしれない。古い価値観の染みはなかなか落ちない。

たまにはフルスクラッチもいいじゃん、という話を書こうと思ってたのにまた長くなりすぎて尻切れ・・・。