レガシーコードのリファクタリング：新たな希望

旅の始まり（「なぜ」）　初めて 2,000 行のファイルを開いたときのことを今でも覚えています…

Dev.to · Jul 30, 2026

旅の始まり（「なぜ」）

初めて report_generator.py という 2,000 行のファイルを開いたときのことを今でも覚えています。それは何年にもわたってパッチが当てられ、微調整され、「クイックフィックス」されてきたモンスターでした。CSV エクスポートに新しい列を追加する必要があるたびに、私は延々と続く if/else ブロックやコピー＆ペーストされたスニペット、tmp、data2、stuff のような名前の変数をスクロールしながら探していました。日付がフォーマットされている場所を探すのに 1 時間かかった後、私はテストをすり抜けてクライアントの請求書を破損させるバグを導入してしまったことに気づきました。

その瞬間は、松明も持たずに暗い洞窟に足を踏み入れるような感覚でした。コードは一応動くことは知っていましたが、壊れやすく、手を付けるのが怖く、変更するたびに爆弾を解除しているような感覚でした。私は自問しました：ゼロから書き直すことなく、この化け物をどのように保守しやすくすればよいか？

答えは、派手なフレームワークや新しい言語ではありませんでした。それはシンプルで繰り返し可能な習慣：小さく、焦点を絞った関数を抽出することでした。

啓示（洞察）

実践はシンプルです。コードのブロックが論理的に 1 つのことを行っているのが見えたら — たとえそれが 3 行だけでも — それを独自の関数に抽出し、どのように行うかではなく、何を行うかを表す名前を付けます。

なぜこれがジャンクヤードでライトセーバーを見つけるような感覚なのか？

可読性が飛躍的に向上する – 関数名がストーリーを語り、本体が詳細を語る。
テストが簡単になる – 抽出された部分を分離してユニットテストできる。
将来の変更が局所化される – 日付フォーマットが変わった場合、散在する 10 箇所ではなく 1 つの関数を編集するだけでよい。
重複が減る – ある部分が抽出されると、同じロジックが他の場所にもあることに気づき、再利用できる。

このステップを省略すると、「スパゲッティコード」になってしまい、単一の責任が多くの場所に分散してしまいます。その代償は？より多くのバグ、より長いオンボーディング、そしてそのファイルを触ることを恐れるチームです。私は、わずかな修正のために安全のために完全な回帰テストスイートが必要になったために、チームが何週間も失うのを見てきました。

その力の使い方（コードと例）

Before – 苦闘

def generate_report(data):
    # 1. Filter active users
    active_users = []
    for u in data['users']:
        if u['status'] == 'active' and u['last_login'] > datetime.now() - timedelta(days=30):
            active_users.append(u)

    # 2. Compute totals
    total_sales = 0
    for u in active_users:
        for o in u['orders']:
            if o['date'].year == datetime.now().year:
                total_sales += o['amount']

    # 3. Format date for header
    header_date = datetime.now().strftime('%B %d, %Y')

    # 4. Build CSV lines
    lines = [f"Report generated on {header_date}"]
    lines.append("User ID, Name, Total Spent")
    for u in active_users:
        user_total = sum(o['amount'] for o in u['orders'] if o['date'].year == datetime.now().year)
        lines.append(f"{u['id']}, {u['name']}, {user_total:.2f}")

    lines.append(f"Grand Total Sales: {total_sales:.2f}")
    return "\n".join(lines)

Enter fullscreen mode Exit fullscreen mode

ここで何が起きているのか？

この関数は 4 つの異なる仕事を行っています：フィルタリング、合計、日付のフォーマット、CSV 出力のアセンブリ。
同じ年チェックロジックが 2 回登場します（売上用とユーザーごと）。
ビジネスが「アクティブ」の定義を変更することにした場合（例：トライアルユーザーを含める）、2 つのループを検索し、見落とすリスクがあります。

After – 勝利

def _filter_active_users(users):
    """Return users who are active and logged in within the last 30 days."""
    cutoff = datetime.now() - timedelta(days=30)
    return [u for u in users if u['status'] == 'active' and u['last_login'] > cutoff]

def _yearly_total(orders):
    """Sum order amounts that fall in the current year."""
    now = datetime.now()
    return sum(o['amount'] for o in o['orders'] if o['date'].year == now.year)

def _format_header_date():
    return datetime.now().strftime('%B %d, %Y')

def generate_report(data):
    active_users = _filter_active_users(data['users'])
    header_date = _format_header_date()
    total_sales = _yearly_total([u['orders'] for u in active_users])  # flatten for simplicity

    lines = [f"Report generated on {header_date}"]
    lines.append("User ID, Name, Total Spent")
    for u in active_users:
        user_total = _yearly_total(u['orders'])
        lines.append(f"{u['id']}, {u['name']}, {user_total:.2f}")

    lines.append(f"Grand Total Sales: {total_sales:.2f}")
    return "\n".join(lines)

Enter fullscreen mode Exit fullscreen mode

何が変わったのか？

各ヘルパーは 1 つのことを行い、そのことの名が付けられています。
年フィルターロジックは _yearly_total に存在するため、ルールが変わった場合に変更する必要があるのは 1 箇所だけです。
メイン関数は今や高レベルのレシピのように読み取れます：ユーザーをフィルタリングし、ヘッダーを取得し、合計を計算し、行を構築する。
新しい列（例：「平均注文額」）を追加するのは、小さなヘルパーへの別の呼び出しにすぎません — ネストされたループを掘り返す必要はありません。

避けるべき一般的な落とし穴

過度な抽出：できるからといって 1 行だけを抽出しないこと。ヘルパーは明確さを追加するものであり、ノイズを増やすものではありません。
名前への実装詳細の漏洩：get_data() は何も教えてくれません。filter_active_users() はまさに何が起こっているかを教えてくれます。
純粋な値を返すことを忘れる：ヘルパーは、明示的な目的でない限り、副作用（外部状態の変更など）を避けるべきです。

これらのガードレールを尊重すると、抽出された関数は再利用可能なビルディングブロックになります — 既存のモデルを壊すことなく、新しい方法で組み合わせることができる LEGO ブロックのようなものです。

この新たな力が重要な理由

私がメソッドの抽出を熱心に始めた後、report_generator.py ファイルは 2,000 行から約 650 行に縮小し、チームの自信は高まりました。

バグ率が低下した – 各部分を分離してユニットテストできたため、CI でテストを書くことでロジックエラーを本番に到達する前に発見できました。
オンボーディングが加速した – 新しいメンバーは、モジュールが何をするのかをより短時間で読み取ることができました。
リファクタリングが安全になった – 日付フォーマッターをタイムゾーン対応版に置き換える場合、1 つの関数を編集するだけで、すべての呼び出し元が自動的に更新されました。

要するに、メソッドの抽出により、恐れられていたレガシーコードベースが、実際に変更を楽しめる場所に変わりました。これは毎日配当をもたらす一種のスーパーパワーです。

あなたの番

現在のプロジェクトで、「神メソッド」のように感じられる関数を選んでください — 少しずつ何でもこなす関数です。10 分間かけて、論理的な塊を 1 つだけ、適切に名付けられたヘルパーに抽出してみてください。テストを実行し、明確さがどのように向上するかを確認し、それを繰り返してください。

最初にリファクタリングする関数は何ですか？コメントでビフォー/アフターのスニペットを共有してください — あなた自身の「新たな希望」がどのように展開するのか、ぜひお聞きしたいです！ 🚀

Read the original source Next news