【コード哲学エッセイ】 汚いコードは恥じゃない。過去の自分と和解する技術

リファクタリングは 「掃除」 ではなく 「対話」 である

「誰だ、こんなクソコード書いたのは！」

深夜 2 時。納期間近のデスマーチ中、僕はモニターに向かって悪態をついていました。

複雑怪奇に入り組んだ条件分岐。
意味不明な変数名。
コピペで増殖した重複ロジック。

修正しようと手を入れるたびに、別の場所で予期せぬバグが噴き出す。まるで地雷原を歩いているような感覚でした。
怒りに任せて `git blame` を叩き、犯人を特定しようとしました。

画面に表示された名前を見て、僕は絶句しました。

`author: ohtoro`
`date: 3 years ago`

犯人は、3 年前の僕でした。

みなさんは、これに似た経験をしたことはありませんか？
かつての僕は、過去の自分が書いた未熟なコードを見るたびに、激しい自己嫌悪に襲われていました。

「なんでこんな設計にしたんだ」
「もっとマシな書き方があっただろう」
「恥ずかしい、消してしまいたい」

そんな感情に突き動かされ、僕はリファクタリングを始めました。
しかし、そのときのリファクタリングは、コードを良くするための建設的な作業ではありませんでした。
過去の恥ずかしい自分を抹殺するための、「証拠隠滅」に近い行為だったのです。

「汚い」 の正体

なぜ、私たちは過去のコードを「汚い」と感じるのでしょうか。
もちろん、客観的に見て可読性が低かったり、保守性が悪かったりすることはあるでしょう。
しかし、「汚い」という感情の裏側には、もっと深い心理が隠れています。

それは、「成長した今の自分」と「未熟だった過去の自分」とのギャップです。

3 年前の僕は、その時の知識と技術、そして置かれた状況の中で、精一杯のコードを書いていたはずです。
もしかしたら、カットオーバー前夜で徹夜続きだったのかもしれません。
あるいは、新しいフレームワークを勉強しながら手探りで実装していたのかもしれません。

今の僕から見れば「汚い」コードも、当時の僕にとっては、納期を守り、クライアントの要望に応えるための、必死の成果物だったのです。

それを「クソコード」と切り捨てることは、過去の自分の努力そのものを否定することに他なりません。

否定から入るリファクタリングは辛い

「汚いから直す」
「恥ずかしいから消す」

否定的な感情を出発点にしたリファクタリングは、精神的にとても辛い作業です。
コードを見るたびに過去の自分の至らなさを突きつけられ、まるで自分自身を攻撃しているような気分になるからです。

そして、焦りや嫌悪感から、大規模な書き換えを強行してしまいがちです。
「全部書き直したほうが早い！」と息巻いて、テストもなしにロジックを破壊し、結果として新たなバグを生み出し、さらなる自己嫌悪に陥る——。
そんな負のループに、僕は何度もハマりました。

しかし、あるプロジェクトでの経験が、僕の考え方を大きく変えました。

レガシーコードの塊のようなシステムを、一人で保守することになったときのことです。
最初は絶望しかありませんでしたが、コードを読み解くうちに、先人たちの（そして過去の自分の）苦悩や工夫の跡が見えてきたのです。

「ここは急な仕様変更に対応するために、無理やり継ぎ接ぎしたんだな」
「ここはパフォーマンスを出すために、あえて可読性を犠牲にしたのかもしれない」

そうやって背景を想像し、過去のコードに「共感」できたとき、リファクタリングの意味が変わりました。
それは「汚物処理」ではなく、過去の自分との「対話」であり、「和解」のプロセスになったのです。

和解とは、許すことではない

誤解してほしくないのは、「和解」とは、汚いコードをそのまま放置していいということではありません。
また、過去の自分を甘やかして「仕方ない」と諦めることでもありません。

ここで言う「和解」とは、理解することです。

なぜそのコードが生まれたのか。当時の制約は何だったのか。
それを理解した上で、「今の技術と知識なら、こうやって助けてあげられるよ」と手を差し伸べること。
それが、僕がたどり着いたリファクタリングの哲学です。

否定ではなく、肯定から入る。
「よく動いていてくれたね。お疲れ様。これからは少し楽になれるように、服を着替えさせてあげるよ」
そんな気持ちでコードに向き合うと、不思議とリファクタリングが楽しくなってくるのです。

和解のための技術的アプローチ

精神論だけではコードは綺麗になりません。
ここからは、僕が実践している「過去の自分と和解するための」具体的なリファクタリング技術を紹介します。

コードに 「手紙」 を残す

リファクタリングをする際、いきなりコードを消して書き換える前に、僕はよくコメントを書きます。

それは未来の自分や、チームメンバーへの説明であると同時に、過去の自分への返信でもあります。

// Before: 謎の定数が埋め込まれている
if (status === 4 || status === 9) { ... }

これを見て「マジックナンバーやめろ！」と怒るのではなく、まず調査します。

そして、こう書き換えます。

// Refactoring: 4 は「キャンセル済み」、9 は「期限切れ」を意味していた。
// 当時の仕様書（v1.2）によると、これらは再決済不可ステータスとして扱われる。
const IS_CANCELLED = 4;
const IS_EXPIRED = 9;

const isPaymentNotAllowed = (status: number) => {
  return status === IS_CANCELLED || status === IS_EXPIRED;
};

if (isPaymentNotAllowed(currentStatus)) { ... }

このように、「なぜそう変更したのか」という意図をコードやコミットメッセージに残すことが、過去の文脈を尊重しつつ、未来へつなぐ「和解」のアクションです。

ボーイスカウト・ルールと 「ついで掃除」

「来た時よりも美しく」というボーイスカウトのルールは、リファクタリングの基本です。

しかし、ここで重要なのは「森全体を焼き払って更地にする」のではなく、「落ちているゴミを一つ拾う」くらいの感覚で行うことです。

機能追加のついでに、変数名を一つわかりやすくする。
バグ修正のついでに、長すぎる関数を二つに分ける。

この「ついで」の積み重ねが、過去の自分との穏やかな和解につながります。
一気にやろうとすると、「過去の負債」という巨大な敵と戦うことになり、疲弊してしまいます。
毎日少しずつ、通りかかった場所だけを綺麗にする。それだけで十分なのです。

テストという 「命綱」 を渡す

過去のコードが変更を拒む最大の理由は、「壊れるのが怖いから」です。
当時の自分も、触るのが怖くて、継ぎ足し建築をしてしまったのかもしれません。

だからこそ、今の自分が最初にしてあげるべきことは、テストを書くことです。
既存の挙動を保証するテスト（Characterization Test）を書くことで、初めて安心してリファクタリングという手術が可能になります。

「君の書いたロジックは、今のままでも正しく動いているよ。だから安心して変わっていいんだよ」

テストコードは、過去のコードに対する、そんな優しいメッセージなのです。

コードは成長の記録

もし今、あなたが自分の書いたコードを見て「汚い」と感じているなら、それは喜ぶべきことです。

それは、あなたが当時よりも成長し、より良い書き方や設計を知っているという証拠だからです。

一生懸命書いたコードが、1 年後も「完璧だ」と思えるなら、それは 1 年間何も成長していないことと同じかもしれません。

リファクタリングとは、過去の自分を否定する作業ではありません。
成長した今の自分が、過去の自分を助けに行き、共に未来を作るための共同作業です。

画面の中の汚いコードは、恥ずかしい過去の遺物ではありません。
それは、あなたがプログラミングと格闘し、悩み、乗り越えてきた、尊い戦いの記録なのです。

だから僕は今日も、エディタを開き、3 年前の自分にこう語りかけます。

「やあ、久しぶり。また一緒に、いいモノを作ろうか」

あわせて読みたい

過去の自分や失敗とどう向き合うか、あるいは技術的な成長をどう捉えるかについて、以下の記事でも深く掘り下げています。

吃音というコンプレックスと向き合い、それを表現の武器に変えていった僕の原点とも言える物語です。

「弱さ」を「強み」に変えるプロセスは、汚いコードとの和解にも通じます。

こちらはより実践的な「大掃除」としてのリファクタリング宣言です。
本記事の精神論をベースに、具体的にどう動くかを記しています。

燃え尽き（バーンアウト）からどう立ち直ったか。
自分を否定せず、休むことを許し、再び情熱を取り戻すまでの記録です。

ひとりごと

「汚いコード」にイライラしていた頃の僕は、実はコードではなく、思い通りにいかない自分自身にイライラしていたのだと思います。

完璧主義で、弱みを見せるのが怖かった。でも、フリーランスとして長くやっていく中で、「弱さ」や「未熟さ」もひっくるめて自分なんだと受け入れられるようになりました。

今日の記事を読んで、もしあなたの HDD（SSD）の片隅に眠る「封印したいプロジェクト」のことを思い出したら、そっと開いてみてください。
きっとそこには、今のあなたに繋がる大切なヒントが隠されているはずです。

まずは、変数名をひとつ変えることから。
過去の自分との対話を始めてみませんか？