Sider Blog

コードレビュー自動化サービス「Sider」を運営するSider株式会社のコーポレートブログです。

2019年6月度の解析ツール更新を行いました

Siderは毎月解析ツールのバージョンを見直しております。このたび、6月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、Ruby gems(RuboCop, Reekなど)およびnpmパッケージ(ESLint, TSLint, stylelint)に関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

解析結果画面で、目的のIssueを絞り込めるようになりました

解析結果画面でIssueをさまざまな条件で検索・絞り込みが行えるようになりました。 この機能では、解析ツール名やルールIDでIssueを絞り込める他、ディレクトリツリーからの絞り込みも行うことができます。

解析結果画面で表示されているIssue件数が多い時、フィルタリング機能を使うことで表示件数を減らし、Siderを利用したレビューをより行いやすくします。

Issue検索機能

f:id:a_ksi19:20190610171205p:plain

この機能は解析結果画面の「高度な検索」から利用することができ、ツール名やルールIDを選択することでIssueを絞り込みます。 絞り込み時に検索モーダルから表示されていないルールIDなどは、テキストエリアに入力することで絞り込むことも可能です。

f:id:a_ksi19:20190610171316p:plain

ディレクトリツリー

ディレクトリツリーは解析結果画面左側にあるトグルボタンから開くことができます。ディレクトリツリーに表示されるのは、Siderが報告したIssueがあるファイルに限られ、目的のファイルやディレクトリを選択することでIssueを絞り込むことができます。

f:id:a_ksi19:20190610171343p:plain

今回の機能やその他Siderの機能やUXについて、お気づきの点やご要望がありましたらSiderプロダクトチームにお知らせください!

2019年5月度の解析ツール更新を行いました

Siderは毎月解析ツールのバージョンを見直しております。このたび、5月分のバージョンアップデートを行いましたのでお知らせいたします。

Siderは毎月解析ツールのバージョンを見直しております。このたび、5月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、Ruby gems(RuboCop, Reekなど)およびnpmパッケージ(ESLint, TSLint, stylelint)に関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。

Siderでプロジェクトの知識をチームに広げる

Siderでサポートしているツールのうちの三つ、QuerlyPhinderGoodcheckはSider自身が開発しているものです。*1 *2

f:id:soutaro:20190510231121p:plain

これらのツールは

特定のテキストのパターンを発見したときに、なんらかのメッセージを表示する

という動作をします。とても単純な機能ですが、これをどう使えば良いのでしょうか?

チームの知識、経験、歴史

ちょっと一般的な話をしましょう。

コードレビューには「問題があるコードを見つけて修正を促す」という品質に対する効果もありますが、それよりも実際に高く期待されているのは「チームの情報共有を進める」という効果だと言われています。「チームに長くいる人が、過去にチームで発見されたベストプラクティスについて伝える」「以前発生した障害のことを覚えている人が、新しく書かれたコードに似たパターンを見つける」「既に定義されているSASSのmixinについて教えてあげる」こういった、チーム内での知識共有を通して、チームは成長していきます。

一番良いのは開発者同士でレビューして知識を伝えていくことですが、これを多少なりとも自動でやるにはどうしたらいいでしょうか?

Linterでやることもできなくはありません。Linterが提供している組み込みのルールはあなたのチームについての知識を持っていないので、プラグインに相当する仕組みでルールを追加する必要があります。まあ面倒ですよね……一般的なLinterのルールは、それなりに複雑なので、普通のプラグインの仕組みは結構複雑なルールを書けるようになっています。つまり開発のコストが大きすぎる。

「これはチーム全体で知っておいて欲しいことだ!」となにかを思いついた直後に、3分くらいで実装できないといけませんが、プラグインでは困難です。本当はルールを手動で書くこともしたくないのですが、人間のコミュニケーションから自動的に抽出するというのはあまりに難しいのでひとまず諦めましょう。そもそもGitHubとかSlackとかに完全にコミュニケーションが乗っているわけでもないので、まあ無理です。

その辺りをSiderチームで詳細に検討した結果、「パターンにマッチしたメッセージを表示する」くらいのメカニズムが適当なのではないかな、ということになりました。説明に戻ります。

カスタムルール

Siderでは、これを「カスタムルール」と呼んで、自分でルールを追加・定義できるLinterとして活用することを提案しています。プロジェクト内で定義されたAPIについてなんらかの注意事項を表示したり、言葉の利用方法についてレビューで注意したり、オペレーションの手順を表示したりできます。

rules:
  - id: remove_column
    pattern: "remove_column(...)"
    message: カラムを削除するときは https://eagletmt.hateblo.jp/entry/2017/09/24/004709 を読みましょう

これはQuerlyの例ですが、remove_column(...)というテキストでパターンを定義し、remove_columnメソッドの呼び出しを検出します。この例では、 remove_column するときの注意事項について説明したブログの記事を紹介していますが、例えばプロジェクトによっては単に「カラムを削除するな」と言うかもしれません。*3

引数の数以外(レシーバも条件にはできますが)で、メソッド呼び出しを特定することはできないというのがポイントです。このくらいなら、パターンの構文を覚えればすぐに書けるようになるし、書きたいものは大体書けます。(「大体」は言い過ぎかもしれませんが、まあ意外と書けます。)ここでは書いていませんが、パターンをユニットテストする仕組みも用意していますので、

  1. チェックしたいことを考える
  2. パターンを考える
  3. テストを書く

まで、YAMLファイルを少し編集すれば書けるようになるのです。

また、多少一般的な感じのルールは、Twitterで紹介しています。「実際にどんなルールを書いたら良いのか??」と悩んだときにご覧ください。

誤検出について

Querlyなどの紹介をしたときに必ず聞かれるのは「誤検出があるのではないか?」ということですが、これについては「そういうもんですが、まあトータルで見たときには利益の方が大きいのでは」というのが私たちの回答になります。

まず、誤検出を減らすことがあまりできない設計になっているのは、意図的なものです。誤検出を減らすためには、高度なプラグラミングが必要になります。簡単に言うと、パターンの正確さと定義のための労力にはけっこうな関連があります。Siderでは、「あんまり深く考えないでルールをたくさん作ってもらう方が利益が大きい」という戦略を採用しています。

誤って検出されたメッセージについては、「Siderからクローズする」という運用を提案しています。Siderでは、

  • GitHubのPull Requestで変更したところに関連するメッセージしか表示しない
  • 不要なメッセージを気軽に「クローズ(無視)」できるようにする

という工夫があり、誤検出に負けないユーザー体験を提供しています。

逆に言えば、Sider以外でこれらのツールを使おうと思ったときには、残念ながら少し厳しい体験になるはずです。例えば、手元の開発環境でエディタでソースコードを編集している最中に実行しようとすると、「Pull Requestの情報がないので、全部のコードに関する問題を表示する必要があり、誤検出が多すぎて厳しい」ことになるでしょう。*4

極端なことを言えば、「パターンにマッチしたメッセージを表示する」というのはおまけで、「リポジトリにチームの知識が明文化されて残っていく」ということがより重要です。

まとめ

Siderでは、コードレビューの大きな目的の一つである「チーム内の知識共有」について注目し、製品の開発を行っています。通常のLinterが検査する一般的なルールだけではなく、チームの知識をルールとして簡単に記述できるツールを開発しています。Siderを使って、チームの知識をファイルに書き、自動的に共有していきましょう。

リファレンス

*1:実はQuerlyは id:soutaro が開発しているものですが。

*2:俺がSiderだ。

*3:id:gfx提案により、例を書き換えました。

*4:というのも少し雑な説明で、reviewdogとかprontoとかを使えば、それなりに戦うことができる気はします。

2019年4月度の解析ツール更新を行いました

Siderは毎月解析ツールのバージョンを見直しております。このたび、4月分のバージョンアップデートを行いましたのでお知らせいたします。

現在のバージョンについてはドキュメントもあわせてご確認ください。

なお、Ruby gems(RuboCop, Reekなど)およびnpmパッケージ(ESLint, TSLint, stylelint)に関しては、それぞれ任意のバージョンをSider上で動作させることが可能なため、上記のアップデートはデフォルトバージョンの更新になります。詳しくはドキュメントの各解析ツールの設定をご覧ください。

何かご不明点がございましたら、お気軽にSiderの右下のチャットからお問い合わせください。