Reek の Collaborateur になりました
こんにちは。 先日、Reek の Collaborateur になりました。Collaborateur とは、GitHub でマージボタンを押せる人です。
結構うれしいので、ブログを書きました。
TL;DR
ある朝起きたら Reek のコミット権をもらっていた。
Reek とは?
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を使用している周りの修正を行っていました。
そのため、実は Reek のコアである臭いを検出する部分に関しては、まだあまり理解していません…。 今後はそういうところにも手を出しつつ、開発者にとってよりよい環境を提供するために Reek を改善していけたらな、と思っています。