キャリア
ほとんどのリライトはビジネスのためではなくエンジニアのために行われる
Most rewrites serve the engineer, not the business (anatoliybabushka.com)
要約
この記事は、既存のコードを書き直す動機が、ビジネス価値よりもエンジニアの個人的な好みや学習意欲に偏りがちであることを指摘しています。長年稼働しているコードは、過去のバグ修正の履歴であり、安易なリライトはその「記憶」を失わせるリスクがあります。真にリライトが必要なのは、ランタイムのEOL、主要な依存関係の廃止、特定の機能を実現できないといったビジネス上の明確な理由がある場合のみであり、AIを活用したリライトも、この本質的な問題を解決しないと筆者は主張しています。
全文翻訳
ほとんどのリライトはビジネスのためではなくエンジニアのために行われる
2026年6月30日 · 5分で読めます
ある夏、数週間にわたり、私は午前4時に起きて、雇用主がすでに誰かに書くために報酬を支払ったコードを書き直しました。それは毎日本番環境で実行されており、CakePHPで構築されていました。私はCakePHPをほとんど知らなかったので、すべてのファイルが私には間違って見えました。私はLaravelを知っており、そこで働くのが大好きでした。だから、自分の時間で、頼まれもしないのに、そのシステムを少しずつ移植し、古いフレームワークがなくなるまでIlluminateパッケージに置き換えました。私たちはそれをマージしました。次のプロジェクトもLaravelで始めました。そして、それがなぜやる価値があったのか、一度も説明することはありませんでした。なぜなら、少なくともビジネスにとっては、やる価値がなかったからです。そのアプリケーションは、以前と同じユーザーに同じ速度で同じ仕事をしていました。リライトは、たった一つのことだけを改善しました。それは、コードが私にとってどう感じられるか、です。それが、名前を付ける価値のあるパターンです。ほとんどのリライトは、給料を支払っている会社のためではなく、エンジニア(何を学びたいか、何が彼らの趣味に反するか、面接で何が良いか)に応えるものです。
稼働中のコードは、誰かがすでに修正したバグの台帳である
リライトに対する最も強力な反対意見は、労力ではありません。それは「記憶」です。何年もの間本番環境で実行されてきたコードは、誰かが遭遇して密かに修正したすべてのバグの記録です。奇妙な条件分岐、疑わしいタイムアウトを伴うリトライ:そのほとんどは瘢痕組織であり、それぞれの瘢痕はあなたが一度も目にしなかったインシデントを示しています。Joel Spolskyは2000年にこの点を指摘し、完全なリライトをソフトウェア会社が犯しうる最悪の戦略的間違いだと呼びました。コードを捨てれば、修正も捨ててしまいます。そして、同じバグに、本番環境で、同じユーザーの前で再び遭遇することになります。私は10年以上前のPerlシステムと、同じくらいの年齢の自家製PHP CMSで働いたことがあります。どちらも、今日の私が書くようなものとは似ても似つきませんでした。どちらもただ動いていました。会社はそれらに再投資することはありませんでしたが、それが正しい判断でした。そのコードはとっくの昔に元が取れており、トラフィックをさばき続けた穏やかな年々はすべて純粋な利益でした。
不慣れは壊れていることと同じではない
私の話で私が見落とした兆候がこれです。私はCakePHPのコードが間違っていると確信していましたが、実際にはCakePHPを学んだことがありませんでした。不慣れは壊れていることと同じではありません。ツールをよく知らないと、それを使って構築されたものはすべて間違いに見えます。なぜなら、選択の背後にある理由がまだ見えないからです。「これはすべて間違っている」という感覚は、多くの場合、あなたがまだ理解していないという音にすぎません。反対の仮定から始めてください。あなたの前の人々は愚か者ではなかったと。彼らはその時点でのユースケースと制約に合った選択をしました。コードは、たとえその理由があなたには見えなくなっていても、理由があってそのように形作られています。
触れるのが正しい判断であるとき
これらすべてが、すべてを凍結することを意味するわけではありません。「壊れていなければ触るな」という怠惰な解釈であり、それが2026年にセキュリティパッチのないEOLランタイムを実行することになる方法です。いくつかの負債は本当に支払うべき時が来ます。正直な強制機能はこのようなものです – 完全なリストではありませんが、私が繰り返し遭遇するものです。
ランタイムまたは主要な依存関係がEOLであり、公開されたCVEがあり、アップグレードパスがない。
システムを理解している人が一人だけいて、その人が退職を通知したばかりである。
デザインのせいで、すべての新機能が本来かかるべき費用の3倍かかり、その傾向を示すことができる。
ビジネスが、現在のコードでは成長するようには形作られていなかった能力を必要としている。
最後のものが、私が今いる状況です。私はサービスを書き直しています。AIコーディングエージェントがタイピングの多くを行っています。なぜなら、それが構築されていないことを行う必要があるからです。コードは動いています。ビジネスはそれを超えて成長しました。それは、その背後に数字がある理由です。真のリライトと虚栄のリライトを区別するテストは単純です。痛みに数字をつけられますか?CVE、速度への税金、雇えない人材、見逃すローンチ。もし数字が現れないなら、あなたが持っているのはスタイルの好みであり、コードではなく忍耐力の方にメンテナンスが必要です。
AIはリライトのタイピングを安価にし、正しく行うのを同じくらい難しくする
AIはこの計算を変えますが、ほとんどの人が主張するような方法ではありません。新しい議論は、リライトが再び安価になったということです。モデルはモジュール全体を午後中に移植できるので、やらない手はないと。しかし、タイピングはリライトのコストのかかる部分ではありませんでした。再発見がそうでした。エージェントは数分で代替コードを生成します。なぜ古いコードがその奇妙なタイムアウトを持っていたのかは知りません。なぜなら、その理由は2021年のSlackスレッドと、誰もソースからリンクしなかった事後検証に存在するからです。だから、それはクリーンで妥当なものを生成し、瘢痕組織は取り除かれます。あなたはそれをデプロイし、古いバグに再び遭遇します。今回は、最初の作者が修正したときに持っていたコンテキストなしで。自身の修正を忘れたコードを高速に生成することは割引ではありません。クリーンなバージョンも愛され続けることはありません。今日のコードが誰か他の人の間違いの山のように読めるのは、それが現実との接触を乗り越えてきたからです。AIが書いた代替コードも同じ運命をたどります。2年後、あるエンジニアがそれを開き、なぜそのように形作られているのか理解できず、「適切に」書き直したいという全く同じ衝動を感じるでしょう。より安価な生成は、そのループを終わらせるものではありません。それはループを開始しやすくし、停止しにくくします。抜け出す方法は、遅いモデルではありません。それは、理由を平易な言葉で書き記すことです。そうすれば、次の人、あるいは次のモデルが、何だけでなく、なぜを理解できます。だから、動いているものを書き直す前に、数字を探しに行ってください。もし見つからないなら、メンテナンスが必要なのはあなたの忍耐力であり、コードではありません。