Goプロジェクトの“爆速”リファクタリングを実現する！

by pyamain 日々on 投稿日:

パッケージ名変更と参照アップデートを一挙にこなす「pachanger」を使いこなそう

Goの大規模プロジェクトを運用していると、次のような悩みはありませんか？

  • 「パッケージ名を変えたい。でも既存ファイルで大量に参照してるから、変更が大変そう…」
  • 「別ディレクトリにファイルを移動して名称を整理したいけど、他のファイルの参照先を書き換えるのが面倒すぎる…」
  • 「リファクタリングするたびに動かなくなるコードの修正に追われる…」
  • 「パッケージがでかすぎてビルドやテストが遅い」

これらを“爆速”で解決してくれるのが、pachanger です。

この記事では、pachangerの基本的な使い方と、実際のユースケースや運用上のコツを紹介します。
「パッケージ名変えるとか怖すぎ…」から「このツールでパッケージ名を自由に変更できる！」 へと意識が変われば、あなたのGoプロジェクトの開発体験が大幅に向上するでしょう！

1. pachanger ってなに？

pachanger（パチェンジャー） は、Go言語で書かれたファイル群の中から特定のファイルを選び、そのパッケージ名を新しく変えつつ、ほかのファイル内の参照も自動的に書き換えてくれるリファクタリングツールです。

  • ターゲットファイルのパッケージ名を変更
  • 変更後のパッケージやシンボル（型、定数など）を他ファイルで参照している箇所を正しく置き換え
  • シンボル名の一部プレフィックス削除など、細かい操作にも対応

これにより、「ある機能を別パッケージに切り出したい」「とりあえずutilsに入れていたものをもっと適切なパッケージ名にしたい」というシチュエーションで、ほとんど手作業なしでリファクタリングを実現できるのが魅力です。

2. 使い方

pachanger はCLIツールとして動作します。以下は最低限の使い方の例です。

# インストール
go install github.com/pyama86/pachanger@latest
or
brew install pyama86/homebrew-ptools/pachanger

# 使い方
pachanger --file ./path/to/target.go \
          --new newpkg \
          --output ./path/to/output.go \
          --delete-prefix Old \
          --workdir /path/to/project/root \
          --tags test

コマンドオプション

  • --file: パッケージ名を変更したいターゲットファイル。必須。
  • --new: 新しいパッケージ名。必須。
  • --output: 出力先ファイルを指定（省略すると同じディレクトリに上書き）。
  • --delete-prefix: シンボル名の先頭から削除したいプレフィックス。
  • --workdir: どのディレクトリをベースにパッケージを探索するか。(go.modがあるディレクトリを指定)
  • --tags: ビルドタグを指定し、特定のタグ付きソースコードを読み込んだり除外したりできる。

実行すると、

  1. 指定したファイルのパッケージ名を --new で与えたものに変更
  2. 同時に、同じパッケージ（旧パッケージ）を参照しているコードを全自動で書き換え
  3. 結果を --output 先に書き出す
  4. 他の .go ファイルにも変更があれば、上書き保存

といった一連の作業を一瞬でこなしてくれます。

3. 具体的なユースケース

ユースケース1: “とりあえず集めちゃった”ユーティリティパッケージを整理

開発を急いでいると、ついutils や helpers のようなパッケージに、「なんとなく便利なもの全部」を詰め込みがち。
後から見てみると「パッケージ規模が巨大になりすぎ」「依存関係がスパゲッティ化」という惨事が起こります。

そこでpachangerの出番です！

  1. utils 内の特定ファイルだけを新たなパッケージ encodeutils に変更。
  2. ほかのファイルに散在している utils.MyEncoder の参照も自動で encodeutils.MyEncoder に書き換え。
  3. 依存先ファイルの修正を手作業で探す必要がなくなる。

これだけで、「巨大utilsパッケージから一部のコードを抜き出して本来あるべき配置に移す」タスクが、驚くほどスムーズに完了します。

ユースケース2: プレフィックス付きシンボルをスリム化

Goコードでは、構造体名や定数名に「パッケージ名を匂わせるプレフィックス」を付けていたりします。たとえば ModelUser や CtxSomething など。しかし、Goでは名前空間的にはパッケージが役割を果たすため、冗長に感じる場合も多いですよね。

pachangerの --delete-prefix オプションを使えば、ターゲットファイル内のシンボル名先頭の文字列を一括で削除できます。
「ModelUser を User に変更しつつ、他パッケージの参照は db.ModelUser → models.User」のように置き換える、なんてこともお手軽です。

ユースケース3: テストコードだけ別パッケージにする

ときには、テストコードを別パッケージ（_test 形式など）に分離したいことがあります。
たとえば、internal フォルダにある特定のテストファイルを internal_test パッケージにして外部から同様の形でテストできるようにする… などのシーンです。

  • --file でテストコードの .go ファイルを指定
  • --new で _test パッケージ名を指定
  • 他のテストコードがそのファイルを参照していた場合も一緒に書き換え

これにより、テストパッケージの切り離しが一気に進みます。

4. 運用時のコツ

  1. まずGitのブランチを切りましょう
    • 大きな変換になる場合、手元で作業用ブランチを作ってコミット単位で確認できるように。
    • リファクタ後、Goのビルドやテストが通るか確認してから本流ブランチに取り込みます。
  2. --tags オプションを活用
    • プロジェクトにビルドタグがある場合、--tags "integration" のように指定しておくと、ちゃんと該当ソースファイルも解析対象に含まれます。
    • テスト専用タグなどでコードが分岐するプロジェクトでは必須の場合も。
  3. 「まず結果を見る→必要があれば手修正」というスタンス
    • pachangerはスーパーマンではありません。循環参照やパッケージ内のプライベート関数などプロジェクト特有のケースでは、「とりあえず機械的にやってみて、想定と違う箇所だけ手で直す」のが安全かつ速い。
    • それでも大量のファイルを書き換える手間を大幅に省いてくれる点は変わりません。
  4. CIなどと組み合わせる
    • 大きなリファクタリングを行う場合、CIパイプラインの中で自動テストを走らせて「書き換え後のコードが動くか」をチェックするのがおすすめ。
    • カバレッジを見ると、どの程度のコードが「新パッケージ化の影響をテストできているか」も分かります。

5. おわりに

pachanger は、Goのリファクタリングを前向きに、大胆に、そして爆速で進めるためのツールです。
地味に時間と神経をすり減らす「参照先の書き換え作業」を、一気に自動化してくれます。

「パッケージ名を変える」「シンボル名のプレフィックスを外す」というのは、コードを美しく保つために欠かせない作業ですが、日常的に行うにはどうしても億劫になりがち。でも、pachangerを導入すれば、「やりたいときに、やりたいだけリファクタ」 できる環境が手に入ります。

もしあなたのGoプロジェクトが「パッケージ構成がごちゃごちゃになってきた…」とか、「保守しづらい名前が散乱している…」といった状態なら、ぜひpachangerを試してみてください。
スムーズなリファクタリングと開発効率の向上が、あなたのチームを強力に後押ししてくれるはずです。

Happy Refactoring with pachanger!