Railsでのコード削除の手順

Ruby on Railsで、ある機能が不必要になったときにはコードを削除しますが、その際に従うべき確認の流れや削除対象について紹介します。

必ずしもこの順番で削除しなければいけないわけではありませんが、いきあたりばったりで削除するよりも効率的で、抜け漏れが防げるメリットがあります。

なお、削除対象のファイルや関数はリスト化し、各ステップで新たに見つかる度に追加するとよいでしょう。

削除すべき機能やページを確認する
Routesとコントローラーの確認
Viewのコード確認
削除対象チェックリスト
DBビュー、カラム、テーブルの削除についての補足
削除後のテスト

1. 削除すべき機能やページを確認する

実際にRailsサーバーをローカルで起動し、削除対象のページや機能にアクセスします。APIならば、実際にリクエストを投げてみます。こうすることで、確実に使っていないことの再確認ができると共に、出力されるログによって使われているファイルやDBテーブルが確認できます。

また、「不要コードの削除」の記事で紹介したように、機能実装時のブランチやPRを確認すると削除漏れを防ぐことができます。

また、削除対象かもしれないと思ったメソッドや定数は、LSPの参照機能やgrepを使って他に使われている箇所がないかを確認します。Railsではスネークケース（some_class)とキャメルケース（SomeClass）両方が使われるので、grepを使う場合は-E（extended regular expression）と-i（case insensitive）を使って正規表現で両方のパターンでマッチするように検索します。対象ディレクトリはアプリケーションによって異なりますが、”app config db lib spec”でほぼカバーできるはずです。

grep -Erin some_?class app config db lib spec

2. Routesとコントローラーの確認

rails routesコマンドで対象のURLパスとコントローラーの確認を行います。アプリケーションがそれなりの大きさだと膨大なリストになる場合もあるので、grepでフィルタリングします。

例えば、ブログ記事関連機能がPostという名前のモデルの場合、以下のようにフィルタリングします。

# ブログ記事関連(post）のURLのみ表示
rails routes | grep post

該当URLパスと対応するコントローラーのアクションがわかったら、config/routes.rbと該当コントローラーファイルを開き、削除対象の箇所であることを確認します。

また、コントローラーファイルでは以下の項目を確認し、削除対象リストに追加を検討します。

・extendやincludeでどのようなモジュールが読み込まれているか。

・どのようなモデルが使われているか。

・メーラーやジョブは使われているか。

・どのViewファイルがレンダリングされているか。

3. Viewのコード確認

もしAPIモードで使用している場合は、jsonレンダリング以外はviewを使わないと思いますので、このステップはスキップください。

使われているViewファイルを確認できたら、そのファイルを開きます。確認すべき箇所は以下の通りです。

・どのヘルパー関数が呼ばれているか。

・どのようなjavascriptが使われているか。

・どのようなCSSが使われているか。

・どのようなモデルが使われているか。一般的にViewでActiveRecordを直接使うのはアンチパターンですが、フォームや翻訳でモデルが使われている可能性があります。

・どのようなパーシャルがレンダリングされているか。ログでも確認できますが、条件分岐があるとログ出力されていない場合もあるので、コードでも直接確認します。

・どのレイアウトファイルが使われているか。もし複数のレイアウトがあるなら、どれが使われているかを確認します。これはviewコードからはわからないので、ログ出力で確認します。

4. 削除対象チェックリスト

全てを網羅しているわけではありませんが、Railsでの機能削除の際に対象になる可能性があるものは以下の通りです。

config/routes.rb内のRoute
パーシャルやレイアウト含むViews
Viewsで使われているjavascript
Viewsで使われているcss
Viewsで使われているヘルパー
コントローラー
コントローラで使われているConcern
モデル
モデルで使われているConcern
モデルと関連するDBテーブル、カラム、ビュー（*下記に補足あり）
メーラー及び関連Views
ジョブ
Rakeタスク
翻訳ファイル
設定ファイル（.envやenvironments）
ライブラリ（Gemfile記載のGemやvendor）
テスト（rspec等）

5. DBビュー、カラム、テーブルの削除についての補足

マイグレーションを作成し、削除対象の機能でしか使われていないDBカラムやテーブルを削除します。

# テーブル削除のマイグレーション作成例
rails generate migration DropExamples

# カラム削除のマイグレーション作成例
rails generate migration RemoveColumn1FromExamples

もしDBビューを使っており削除対象のカラムやテーブルが含まれている場合、DBビュー定義からカラムを除外してから、カラムを削除するようにします。順番が逆になると、存在しないカラムがDBビューに含まれてエラーになりますので気をつけましょう。

ビュー定義の更新は、新しいview定義ファイルをdb/viewsディレクト内に作成した後、update_viewメソッドで行います。

# bash
rails generate migration UpdateExampleView2

# マイグレーションファイル
def change
  update_view :example_view, version: 2, revert_to_version: 1
end

カラムの削除にはremove_columnメソッドを使います。ロールバック可能なように、カラム定義も記載するようにしましょう。

def change
  remove_column :examples, :column1, :string, default: "", null: false
end

もしモデルがActiveRecord::Baseのサブクラスだった場合、対応するデータベーステーブルもdrop_tableメソッドを使用して削除します。ここでも、ロールバック可能なように各カラム定義やインデックス定義を記載します。

def change
  drop_table :users do |t|
    t.string "email", default: "", null: false
    t.string "name", default: "", null: false
    t.datetime "created_at"
    t.datetime "updated_at"
    t.index ["confirmation_token"], name: "index_users_on_confirmation_token", unique: true
  end

6. 削除後のテスト

一通りコードを削除したら、自動テストを実行して他の機能にデグレが発生していないかをチェックします。

また、コードレビューで削除漏れがないかや、削除すべきでない箇所も削除していないかなどをチェックしてもらいます。

まとめ

Railsでのコード削除の際には、決まった手順を踏み、削除対象になる可能性があるもののリストを順番に確認することで、削除漏れを防いだり効率よく作業ができたりします。

エンジニア術