目次
この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
Ruby でコーディングルールを設けるのに役立つ gem「Rubocop」をチームで利用するメリットとデメリットについて紹介します。
■ はじめに
チームでプログラミングをするときに立ちはだかる壁のひとつに「コードの統一」があると思います。
どんなに有能な人が複雑な機能を瞬く間に作り上げたとしても、チームで開発し保守する以上は、それが他人に理解できるものでなければあまり意味がありません。
なぜならばたったひとりしか理解できないコードは、その人にしか保守できないからです。
この「コードの統一」を図るために出てくるのがコーディングルールかと思います。
コーディングルールがあれば、皆が理解できるコードを共有し合うことができます。
が、このルールを作るのも守るのも面倒くさい！
そこで導入を検討したのが Rubocop です。
この gem は Ruby のコードを静的に評価して「ここはこう書いた方が良いよ」というアドバイスをくれるというものです。
「これがあればコーディングルールなしにキレイなコードを担保できるかも？！」という希望をもとに、新しいプロジェクトで実際に使ってみることにしました。
この記事では、Rubocop をチームで運用してみて感じたメリットとデメリットを紹介したいと思います。
■ Rubocopとは
Rubocop 自体の説明は割愛します。
どんなものかをご存知でない方は下記記事などをご参照ください。
Rubocopを使ってコーディングルールへの準拠チェックを自動化
■ Rubocopの運用方法
今回のプロジェクトでは Rubocop を自動テストの一端として組み込む形で利用しました。
この自動テストと GitLab のマージリクエスト (GitHub でいうプルリクエスト) を組み合わせることで
「テストが成功するまでマージできませーん」という流れができるので、 [45/1090]
Rubocop によるコーディングルールを守らざるを得ない環境を作ることができます。
ただし、Rubocop のデフォルト設定はチームで運用するには敷居が高い内容となっているので最初にある程度縛りを緩くしておき、
また途中からでもメンバーからの意見が多ければ設定を変更する体制を取りました。
■ Rubocopのメリット
ようやく本題になります。
メリットとしては今回挙げるのは下記の３つになります。
1. コーディングスタイルをある程度統一できる
長いメソッド/モジュールの分割をほぼ強制されるので、
数百行のメソッドや数千行のモジュールがプロジェクト内に生まれることがありませんでした。
2. Ruby 歴が短い人、改善意識の高い人の良い矯正になる
Rubocop が提案してくる内容を素直に受け止められる人は、Rubocop 色に染まることで、
どんどん怒られにくいコードを自発的に書く方向に矯正できているように感じました。
メソッドひとつひとつがシンプルになったり、早い時期からメソッド郡のモジュール化を考えたりするようになったり、と良い感じです。
3. Ruby の新しい構文、便利な構文を知る良い機会になる
Rubocop を使っていると「こういう風に書きたいならこう書いた方が分かりやすいよ」という提案を受けることがあります。
これによっていままで知らなかったメソッドや慣習などを学ぶ機会を得ることができました。
■ Rubocopのデメリット
Rubocop 単体のデメリット、というよりも、チームで使う際の注意点というような観点になります。
メリットと同じく、こちらも３つ挙げています。
1. コーディングスタイルをある程度しか統一できない
「メソッドが長いなら分ければ良いんでしょ」と安易に考え、
「method1」「method2」「method3」…のように無意味な名前でメソッドを分割するケースがありました。
残念ながらいま現在の Rubocop はそれを良しとして通してしまうため、
ただ単にメソッド１つの長さが短いだけの、本質的に意味のないメソッド分割を許容してしまうことがあります。
この辺は、「なぜ Rubocop を使うのか」についてチームで共通認識を持っておくべきだと感じました。
2. Ruby 歴が長い人、改善意識の低い人の阻害となる
Rubocop の提案を良しとしない人（たとえば手続き的な記述で書いた方が、
それでメソッドが長くなったとしても分かりやすいと考える人、など）とは、当然衝突することになります。
これは本人にとってもストレスですし、嫌々で書いたコードが良いものになるとも思えません。
ただしこれはどんなコーディングルールにも共通することなのかなと思います。
基本的にはルールを尊重しつつ、どうしてもという場合にはルールを見直していくしかないと思います。
3. 急いでいるときなどに本質的でない指摘で開発が止まる
Aさん「急ぎでこの処理を追加して欲しいんだけど」
Bさん「１行追加するだけでできました！」
Rubocop「メソッドが長いのでエラーです」
Aさん「・・・」
Bさん「・・・」
ということが何度かありました（あと１行だけでも追加すれば Rubocop に怒られる、という罠が巧妙に仕込んである）。
こうなってしまえばリファクタリングを余儀なくされることになるので、後のことを考えれば良いことなのですが、その場では大きなストレスになります。
■ さいごに
Rubocop は自分ひとりで利用するのであれば本当に良い味方になると思います。
とくに最近のバージョンはABCメトリクス値の計測も取り入れられて、よりいっそう養成ギブスとしての能力を増しています。
あと、僕個人としては Rubocop が大好きなので心の中でもっと広まれ！と思っています（もっと広まれ！）。
ただしチームやプロジェクトで利用するには使い方に工夫が必要だと感じました。
チームメンバーにコーディングルールの意識をしっかりと共有しておくことである程度は回避可能だと思いますが、もっと良い方法があればぜひ教えてください！
