【コード哲学エッセイ】 汚いコードは恥じゃない。過去の自分と和解する技術
リファクタリングは 「掃除」 ではなく 「対話」 である
「誰だ、こんなクソコード書いたのは！」
深夜 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）の片隅に眠る「封印したいプロジェクト」のことを思い出したら、そっと開いてみてください。
きっとそこには、今のあなたに繋がる大切なヒントが隠されているはずです。
まずは、変数名をひとつ変えることから。
過去の自分との対話を始めてみませんか？
