みんなのウェディング Advent Calendar 2017 の 14日目の記事です。

業務で Rubocop を使っています。ただし、2017年4月まで放置気味でした。
しかし「Rails 5.0 へのバージョンアップ作業過程」で Rubocop もバージョンをアップしました。

2016年1月から 2017年4月まで同じバージョンだった理由

ある日、tachikoma からのプルリクエストのテストが落ちました（当時、平日はtachikoma による gem のアップデートをしていました。現在は deppbot を利用しています）。原因は、Rubocop に入った cop の指摘の対応ができなくて、「あとでやる」と書いてそのまま放置してしまいました。1年ちょっとぐらい...

最新のバージョンにアップした方法

Rubocop の指摘について対応するツールはあるのですが、ツールだけじゃ足りなく1つ1つ潰していく時間が必要でした。1つ潰しては、プルリクエストにしてマージして...を繰り返していきました。当時、テストのカバレッジも低く、手動テストも合わせていました（テストカバレッジについては別な話）。

追加になった cop で気づいたこと

追加になった cop の対応をすすめる時に、指摘されている内容を見ると「なるほど」と思う指摘がありました。そのなかからいくつか抜粋です

Lint/IneffectiveAccessModifier

クラスメソッドなのに、private なのはないよね、という指摘をしてくれます。
指摘されて、「そりゃそうだ」と思ったのを覚えています。

# Bad
class Article
  private
  def self.by_tag_id(tag_id, limit=5)
    ... 
  end
end

# Good
class Article
  def self.by_tag_id(tag_id, limit=5)
    ... 
  end
end

Style/ConditionalAssignment

下記の例だけだとわかりにくいのですが、Ruby っぽい Cop です

# Bad
if foo
  x = 1
else
  x = 2
end

# Good
x = if foo
  1
else
  2
end

余談ですが、Rubocop には、Bad と Good のサンプルがあります。全部にある状態ではないので、「RuboCop のドキュメントに example を追加してみる」を読んで実際に書いてプルリクエストをいくつか出しました（v.0.52.0 に入ってました）。

onkcop の導入

バージョンを上げた後、onkcopを 2017年5月に導入しました。
onkcop を導入した理由は、コードの品質を下げないためです。Rubocop は導入されているけれど、設定が緩めで「意味あるのこれ？」という話から設定を少しづつ厳しくしています。

時々、この設定はナゼ？と思うこともあります。そのときは、プルリクエストや定期的に開催されるエンジニアリングミーティングで話したりしています。

「あとでやる」は「あとでやらない」

ふりかえると、Rubocop の導入自体は大切な一歩です。
Ruby でプログラムを書いた経験の少ない人達で開発を始める時、コードに一定のルールを持たせるために、Rubocop は必要なツールだと思います。
ただし、Rubocop を導入しただけではダメで、「なぜ、その Cop が設定されているのか？」についても考える必要があったのだと思います。そこについて話せないまま「あとで対応しよう」では Rubocop の意味がありませんでした。

とはいえ、まだまだ rubocop-todo.yml をそっと閉じたくなる気持ちが湧く状態です。ここも解消してきたら、また別な知見としてまとめる日が来そうです。