みんなのウェディング 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 をそっと閉じたくなる気持ちが湧く状態です。ここも解消してきたら、また別な知見としてまとめる日が来そうです。