rails 界隈では Sider の普及に伴い rubocop を業務で使っている方も増えてきたのではないでしょうか？
しかしながら、一度荒れ果てた荒野にrubocopを放っても成果はほとんど上がらないことでしょう。
必要なのは、すべてのコードを綺麗にするぞ！という高尚な志ではなく、現実を少し改善すれば、それでOKという意識低い気持ちな気がします。
--lint オプション
rubocopには -l または --lint というオプションがあるのをご存知でしょうか？
こいつはlintオプションと呼ばれるやつで、bugに繋がりやすい警告レベルを指摘してくれます。
こいつをまずデフォルトにしましょう。
.rubocop ファイルに --lint と記述すると、rubocopのコマンドが常に--lintオプションがついた状態で実行されるようになります。
.rubocop ファイルを使うことで、プロジェクトのメンバー全員がそのオプションをつけてrubocopを実行することができるため、「 rubocop -l と実行してください！」などと呼びかける必要がなく便利です。
rubocop_todo.yml と向き合う
次にこの状態で、rubocop_todo.yml を生成します。
rubocop --auto-gen-config
プロジェクトにこれ以上 --lint に違反するコードを入れないようにするためです。
rubocopを入れると、rubocop対応で色々と対応工数が増えてしまうと恐れている方もいらっしゃると思いますが、
この --lint オプションは宗教戦争的なものはほぼなく、バグに繋がる恐れがあるか？という観点での指摘です。
さて、auto-genされた rubocop_todo.yml には問題が山積です。
これらは指摘事項を修正していかなくてはなりません。
todoファイルと向き合いきれなかった場合
rubocop_todo.yml ではルールをファイルあたりで抑制してしまうため、
todoファイルを全部修正できない場合は、問題の箇所を特定してコメントアウトで警告を抑制する方法をとったほうが良いでしょう。
じゃないと、 rubocop_todo.yml に記載されたファイルは治安が悪化して行きます。
一日1cop修正
私のプロジェクトでは1日に一つだけ、これを実行していくことを行いました。
修正はコミットを細かく分けて、tmpブランチからcherry-pickをしてmasterにマージする量を調整する形をお勧めします。
(OSSである dev.to では一つのpull requestがマージされたら新しいpull requestを作るという方法をとりました。)
rubocop_todo.ymlを消すことができれば、これでとりあえずrubocop -lに適応した状態を作ることができたということです。
--lint 以外のオプションと向きあう
次の段階としてrubocop -lをやめて、rubocop.ymlを設定していくというステップがありますが、これは次回以降に。
まずは、--lintで怒られないくらいを目指すのはいかがでしょうか？