pockestrap

Programmer's memo

Reek の Collaborateur になりました

こんにちは。 先日、Reek の Collaborateur になりました。Collaborateur とは、GitHub でマージボタンを押せる人です。

結構うれしいので、ブログを書きました。

TL;DR

ある朝起きたら Reek のコミット権をもらっていた。

Reek とは?

github.com

Reek は Rubyソースコードを静的に解析することで、「コードの臭い」を検出するツールです。

class Article
  def user_fullname(user)
    "#{user.first_name} #{user.last_name}"
  end
end

例えば、上のArticleクラスの定義に対して、Reekは以下のような警告を出します。

[2]:UtilityFunction: Article#user_fullname doesn’t depend on instance state (maybe move it to another class?) https://github.com/troessner/reek/blob/master/docs/Utility-Function.md

この UtilityFunction とはuser_fullname メソッドはArticleの状態には一切関係が無いため、別のクラスに移すべきでは?という警告です。

Reekではこのような「ちょっと設計がおかしいんじゃない?」といったコードに対して「コードの臭い」という形で警告を出します。

RuboCop との違い

Ruby で静的解析ツールと言うと、RuboCop を思い浮かべる方も多いかも知れません。 Reek と RuboCop では、検出する問題の種類に違いがあります。

Reek は先程のような「コードの臭い」を検出するのに対し、RuboCop はインデントのズレといったコードのレイアウトやバグである可能性が高いコードを検出します。

そのため、両者は共存できるツールだと言えるでしょう。

Reek との付き合い方

Reek を使用している感想としては、「なるほどたしかにー」となる警告が多いです。ですが、すぐに直せるものばかりとは限りません。
先程の UtilityFunction の例であれば警告に妥当性がありますしすぐに直せそうです。ですが、直すには色々見直さなければいけない警告などもよく出ます。

ですので 告の意味について考え、直すか直さないかを判断する必要が RuboCop 以上にあると言えるでしょう。

Collaborateur になった経緯

ここ1ヶ月ほど、仕事の関係もあり Reek に何度か Pull-Request を送る機会がありました。

先日わりと大きめの仕様変更を提案し、それを実装してPull-Requestを投げたところ、レビューコメントとともに「コラボレーターにしておいたよ!」と言われていました。 わいわい。

Reek でなにをするの?

これまでのPull-Requestでは、主にRubyソースコードをパースするParser gemを使用している周りの修正を行っていました。

  • UTF-8 として Invalid な文字列リテラルの制御
  • Syntax Error である Ruby ファイルを解析した時のエラーハンドリング

そのため、実は Reek のコアである臭いを検出する部分に関しては、まだあまり理解していません…。 今後はそういうところにも手を出しつつ、開発者にとってよりよい環境を提供するために Reek を改善していけたらな、と思っています。