読者です 読者をやめる 読者になる 読者になる

てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

全社的にRuboCopを導入するための工夫

標準化

エンジニアの id:necojackarc です。

久しぶりのエンジニアブログの執筆です。最近は新サービス fotowa を担当しており、先日まで α 版リリースの締切に向け血で血を洗う激しい戦いを繰り広げていたため、ブログを書く時間が確保できませんでした。

本日はピクスタで全社的に導入している静的コード解析ツールである RuboCop の運用についてご紹介したいと思います。

今回の主なテーマは、

  • どのようにして設定 (コーディングルール) を順守してもらうか
  • どのようにして設定 (コーディングルール) を一斉に適用するか
  • どのようにして設定 (コーディングルール) を更新していくか

の3点です。

背景

RuboCop の全社的な導入を行っていたのですが、馬鹿正直に各リポジトリごとで設定ファイルを管理するのは正直面倒です。つい最近まではその馬鹿正直で面倒な状態になっていたため、RuboCop の共通設定を一元管理できるように工夫を行いました。

また、ピクスタのコーディングルールは正直まだまだ未成熟です。そもそもルールそのものが形骸化していた時期すらあり、現在適用されているコーディングルールも、私が「カオス過ぎるから統一ルール考えた」的なノリで導入したものが元になっています。そのため、ルールそのものに話し合いの余地が大いに残されており、これから「ピクスタのルール」として育てていく必要があります。

RuboCop とは

RuboCop*1 は静的コード解析ツールです。

github.com

デフォルトでは Ruby Style Guide に準じた設定となっています。ピクスタではコーディングガイドに沿った実装になっているかを確認するために、Pull Request 作成時に SideCI を用いて自動で適用を行っています。こういった自動化は全社的に静的コード解析ツールを導入するにあたっては必須だと思います。

CI ツールの活用事例については、SideCI さんによるインタビューを以前受けていますので、興味がある方は以下の記事をご覧ください。

blog-ja.sideci.com

ピクスタのコーディングルール

ピクスタのコーディングルールも、基本的に Ruby Style Guide に準じております。

そもそも Ruby Style Guide の日本語版 が生まれた理由が、「ピクスタのコーディングルールとして Ruby Style Guide を導入したいけど、英語だと全員に周知するのは難しいので id:fortissimo1997 が日本語への翻訳を行った」といったものだったりします。ゆえに現在も日本語版は fortissimo1997 アカウントのリポジトリとして運用されています。

そのため、ピクスタのコーディングルールと RuboCop は非常に相性が良いです。

どのようにして設定 (コーディングルール) を順守してもらうか

先ほど少し説明したように、Pull Request 作成時に SideCI を用いて静的コード解析ツールを行い、新規追加コードに対して Bot に自動でコメントを付けてもらうようにしています。

この際、RuboCop による指摘に対応するまでは、コードレビュー依頼を基本的には行わないようにお願いしています。どうしても対応が難しいものについては、そのコメントに対し一言残すことで、何故今回は無視したのかといったことをレビュアーに伝えるようにしています。また、コメントによる部分的な無効化も可能*2ですので、やむを得ず無視をする場合にはこちらも利用したりします。その際は、可能であればリファクタリングのチケットを立てるなどして、割れ窓を放置しないように心がけています。

どのようにして設定 (コーディングルール) を一斉に適用するか

こちらに関しては「共通部分を一元管理し、差分を各々で定義する」というごく普通の対応を行いました。

RuboCop の 設定ファイルには継承機能があり、URL でリモートファイルの指定もできます。 つまり、リモートファイルに共通部分を切り出せば、そのリモートファイルのみの変更で全てのリポジトリの設定変更が可能になります。

現在は Github 上で共通設定を管理しています。

github.com

具体的な設定例については pixta-rubocop の README をご覧ください。

どのようにして設定 (コーディングルール) を更新していくか

冒頭の背景で述べたように、コーディングルールは「ピクスタのもの」どころか「id:necojacarc がなんか勝手に決めたもの」の状態でのスタートでした。そこで「ピクスタのもの」として育てていくために、気軽に意見が言い合える場を作ることにしました。

これに関しても、以前のブログでも紹介した esa を利用しています。

texta.pixta.jp

気になるルールがあった場合は、

  • Bot に指摘されているコメントの URL を共有する
  • 何故そのルールが気になるのかについて持論を述べる

ようにしました。

それに対して各々が共感を示したり、コード自体の改善案をだしてコーディングルールを擁護したりすることで、可能な限り納得感のあるルール作りを行おうとしています。最終的な結論は、エンジニア全員が揃う週次定例の際に出すことが多いです。

ただ、このやり取りに関しては esa よりも Github の Issues のような形式の方が適切かなと思います。気になるルールごとに Issues を立てて議論を行うことで、各ルールが決まった背景をあとから確認しやすくなります。

そこで、先ほど紹介した pixta-rubocop リポジトリの Issues を活用して、今後は議論を進めていければいいかなと思っています。ただし、公開リポジトリですので、Issues に書ける内容や貼れるコードに制約が出てきてしまう、という欠点はあります。しかし、コーディングルールを公開することと、そこへの変更に対するやり取りをオープンにすることによるメリットもあるのではないかと考えています。

まとめ

ピクスタでは RuboCop を利用したコーディングルールの運用を円滑に行うために、

  • CI ツールによる自動適用を行う
  • 共通設定をリモートで一元管理する
  • 気軽に議論できる場を作る

といった工夫を行っています。

*1:ピクスタでは「るぼこっぷ」と呼ぶ人と「らぼこっぷ」と呼ぶ人が居ます

*2:ref. RuboCopの警告をコメントで無効化する方法