Joel Spolsky の Things You Should Never Do, Part I はデスクトップソフトウェアの文脈を感じるなー。とはいえ最近 Janna Dogan が Twitter でその記事を枕に、
We do tens of thousands if not not hundreds of thousands successful rewrites at this scale as an industry every year. Requirements change, tech stack change, dependencies change, our understanding of the problems change. Rewrites are not just inevitable, it’s the part of the job.
という話をしていたので、やっぱりまだ影響力はあるのかな。
手元のマシンで動かすデスクトップむけのソフトウェアと違って、サーバーサイドだと、新旧のバージョンを混在させて、ランダムに出し分けしながら、段階的に新しいバージョンの割合を増やしていく、とかが簡単なので、書き直しのリスクはそれなりに下げられる。その結果か、社内では色々な書き直しを見かける。新旧のバージョンが一つのサービス小さく混在していることもあれば、新バージョンが新しい別のサービスを呼び出すこともある。morrita さんは
Microservices のような大規模インターネットソフトウェアのリファクタリング・パターンも広く知られるようになった。
なんて書いているけれど、新バージョンが新サービスだったりすると、そのサービスを受け持つチームからすると、それはリファクタリングというよりは書き直しに近い。
リファクタリングの “without changing its external behavior” というのは、どこからみた外部の振る舞いかに依存している。社外に出ているインターフェースがバチっと変わったりするのは少ないはずだけど、社内でそこまで互換性を保つ努力をしているかというと、うーん、大体こんな感じだと思っていただければ…。
再挑戦
私がレビュアーをやっている containerd は、必ずしも Docker を置き換えるわけではないのだけど、Docker の書き直し的な側面があって、細かいデザインが良くなっている。
例えば、containerd では「コンテナのログを CloudWatch みたいな外部のサービスに書き出す」という実装部分を外部のプロセスに追い出せるのだけど、Docker では本体のデーモン自体に繋ぎ込みのコードが入っている。Google Cloud Platform と AWS 両方に対応するために、Docker は両者の SDK をリンクしているし、パブリッククラウド固有のバグを直しても、Docker 本体の次のリリースを待たなくてはいけない。私は containerd に詳しくなってから、トラブルシューティングで Docker の該当部分を読んだので、正直だいぶびっくりした。
もっと大きいところだと、コンテナイメージのレイヤーをファイルシステムにマップする部分は、Docker では graphdriver, containerd では snapshotter と呼ばれている。この二つの違いについて、containerd メンテナの一人、Michael Crosby の Where are containerd’s graph drivers? では
The short answer is that containerd does not have graph drivers, but it does have snapshotters. We didn’t make this change because we wanted to invent something new or had a severe case of NiH (not invented here). We set out to fix a few long standing issues that are caused by the design of graph drivers.
graphdriver の反省をベースに snapshotter をデザインしたぞ、ということが説明されている。
あるいは、Stripe の Ruby 静的型検査チェッカー Sorbet の開発者の一人、 Dmitry Petrashko は、Scala 3 となる Scala コンパイラ Dotty の開発者でもある。プログラミング言語畑は、そういう複数のプログラミング言語にまたがって活躍している人が多いように思う。TypeScript の Anders Hejlsberg は Turbo Pascal からの伝説のプログラマだし、V8 と Dart の人々も、いつのまにかプログラミング言語スタートアップ をやっている。
shinh さんも書いているけれど、こういう、同じ問題を複数回解いている人の得られる洞察ないし知識みたいなものに、私は漠然とした憧れがある。karino さんのモバイル OS 語りとか、morrita さんの Web ブラウザ語りにとかも、そういう気持ちがちょっとあります。
そういえば、最近 ttrpc という containerd の変種 gRPC のコードジェネレーターを書き換えるべく頑張っていて、なにか既視感があると思ったら、私のアルバイトの最初の仕事の一つが、会社の RPC コードジェネレーターの ActionScript プロトタイプ作成だったのを思い出した。
二周目ならば俺 TUEEEE がしたい
一方で、自分が書いたもので書き直したいものはあまりない。仕事で書いたもので、今やり直したらもっと上手くできるものは色々とあるけれど、一方でそれが社運というか、自分や周りの昇進以上の大きな成果を生むかというと、そうは信じきれないところがある。レイオフ語りも、Google と Mozilla を比べるのはだいぶ無理があると思うんですよ。
まあ、実際に過去に戻って書き直しができるわけではないので、そんな「もしも」の話をしても仕方がないといえばそうなんだけど。