コピペプログラミング — 同じコードが増殖する
動くコードをコピペで増やした先で、なぜ「同じバグを何度も直す」羽目になるのかが分かる。DRY原則と、逆に共通化しすぎる罠の見分け方まで。
- コピペプログラミングは、既存のコードを複製して少し変えて使い回すこと。その場は速いが、同じ知識がコードのあちこちに重複して存在することになる。
- 重複した箇所の1つにバグや仕様変更が生じると、残り全部を探して直さねばならない。1つでも漏れると挙動が食い違い、原因の分かりにくい不具合になる。
- 直し方は共通部分の抽出(関数・クラス・モジュール化)。ただし『たまたま似ているだけ』を無理にまとめると逆に密結合を生むため、同じ理由で変わるものだけを束ねる。
動いているコードをコピーして、少しだけ書き換えて別の場所に貼る。目の前の実装は一瞬で終わります。しかしその一瞬の楽が、後で何倍もの手間になって返ってきます。
横にスクロール
症状:どう気づくか
- ほぼ同じコードブロックが、複数のファイルに散らばっている(数行違うだけ)。
- バグ修正のたびに「同じ直しを何箇所にもする」感覚がある。
- grep すると、似た処理が5箇所も6箇所も引っかかる。
なぜ悪いのか
コピペの本当の問題は、コードの行数ではなく、同じ「知識」が複数箇所に重複して存在することです。
たとえば「電話番号を正規化する処理」を3箇所にコピペしたとします。後日、その正規化に不具合が見つかったり、仕様が変わったりしたとき、3箇所すべてを探して、すべて同じように直す必要があります。1箇所でも見落とせば、そこだけ古い挙動のまま残り、「なぜかこの画面だけ結果が違う」という、原因の追いにくいバグになります。コピペした瞬間は3つが同一でも、時間が経つほど少しずつズレていき、どれが正しいのか誰も分からなくなります。
DRY(Don't Repeat Yourself)——「同じことを繰り返すな」。より正確には「あらゆる知識は、システム内で単一・明確・信頼できる表現を持つべき」。重複を消すことが目的ではなく、1つの知識を1箇所にまとめ、変更点を1つにするのが狙いです。
直し方
重複した知識を1箇所に抽出する。 共通処理は関数へ、共通の構造はクラスやモジュールへ。
Before:
userForm.js … 電話番号の正規化ロジック(コピー1)
adminForm.js … 電話番号の正規化ロジック(コピー2)
import.js … 電話番号の正規化ロジック(コピー3)
After:
phone.js … normalizePhone() を1つだけ定義
(3ファイルはこれを import して呼ぶ)
こうすれば、仕様変更も不具合修正も phone.js の1箇所で済み、全箇所に自動的に反映されます。
逆に、たまたま今は似ているだけのコードを無理に1つにまとめると、別々の理由で変わりたい2つが一箇所に縛られ、片方の都合でもう片方が壊れます。見分け方は「同じ理由で変わるか」。同じ仕様に由来する重複はまとめるべき(本当のDRY)。偶然の一致は、無理にまとめず放っておくほうがよい(早すぎる抽象化を避ける)。3回目に現れたら共通化を検討、くらいの温度感が実務的です。
まとめ
- コピペプログラミングは、コードを複製して使い回すこと。その場は速いが、同じ知識があちこちに重複する。
- 害は、重複の1つを直すと全部を探して直す羽目になること。漏れると挙動が食い違い、原因の追えないバグになる。
- 直し方は共通部分の抽出(関数・クラス・モジュール)。DRY=1つの知識を1箇所に。
- ただし共通化しすぎも害。「同じ理由で変わるか」で判断し、偶然の一致は無理にまとめない。
アンチパターン図鑑の記事ガイド
コピペプログラミング — 同じコードが増殖するを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
DRY
比較で見る軸
難易度: basic / カテゴリ: アンチパターン図鑑 / タグ数: 5
導入後に効く点
重複した箇所の1つにバグや仕様変更が生じると、残り全部を探して直さねばならない。1つでも漏れると挙動が食い違い、原因の分かりにくい不具合になる。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- basic
- カテゴリ
- アンチパターン図鑑
- タグ数
- 5
判断チェックリスト
- 自社の用途が「DRY / 重複」に近いか確認する。
- 強みである「コピペプログラミングは、既存のコードを複製して少し変えて使い回すこと。その場は速いが、同じ知識がコードのあちこちに重複して存在することになる。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。