「とりあえず動けばいい」が
生むガラクタの塔
「時間がないから」と根本的な修理を先送りし、
ガムテープで補修し続けた家。
ある日、少しの地震で全てが崩れ去りました。
- 「このコードが何をしているかわからないが、動くから触るな」と言われる場所がある
- 1つの修正をすると、全く関係ない別の場所でバグが起きる
- コードの中に「// とりあえず」や「// 仮修正」というコメントが散乱している
- 新機能を追加するのに、以前の3倍以上の時間がかかるようになった
これ以上、上に積み上げることはできません。
01. 借金で家を建てる
// 無理やりID=99を除外。理由は不明だけどこれで動く
if (user.id == 99) return true;
// 日付バグの応急処置
if (date > '2025-01-01') date = '2024-12-31';
try { ... } catch (e) { /* エラー握りつぶし */ }
バグが出たとき、根本原因（設計ミス）を直すには3日かかります。
でも、「例外処理（if文）」を1行足して誤魔化すだけなら3分で終わります。
忙しい現場では、誰もが後者を選びます。これが「技術的な借金（負債）」の始まりです。
最初のうちは問題ありません。しかし、借金を返済（リファクタリング）せずに借入を繰り返すと、
やがて利息（保守コスト）が膨れ上がり、機能追加という「元本」の返済ができなくなります。
継ぎ接ぎだらけのコードは、誰にも理解できない「現代アート」と化し、誰も触れなくなります。
一瞬の快楽が、未来の自分を殺す。
02. 常にきれいにして帰る
プロの料理人は、調理中もキッチンを常に磨き上げます。
汚れたキッチンでは、最高の料理（コード）は作れないからです。
私たちも同じです。「来た時よりも美しく」。
コードを触るたびに、変数名を分かりやすくしたり、長すぎる処理を分割したりして、
少しずつ借金を返済し続ける文化が必要です。
03. 勇気ある撤退戦
もし、あなたのシステムがすでに「ガラクタの塔」になっているなら。
さらに積み上げる（機能追加する）のはやめてください。
勇気を持って「作り直し（リプレース）」や「大規模改修」を提案する時期です。
崩壊してからでは遅いのです。