普通にみんなやっていることだと思うけど、自分が gem を入れるときに最低限やることをまとめてみた。
何かしらの方法で探してきた gem を「導入するかどうか」の判断をするときにやることです。
やること一覧
- 今後もメンテされそうかを調べる
- README を 全部 読む
- 依存関係を調べる
- ソースコードを読む
今後もメンテされそうか？
ほとんどの gem は GitHub で公開されているので、下記の観点を参考に調べる。
- 最終コミット日時
- 1年前とかだと安定している or 放置されている
- contributes の数
- 多いとメンテされそう
- star の数
- 使用者が多く、問題が報告（修正）されそう
- Releases の数
- 基本機能は安定してそう
- Issues, Pull Requests の数、対応状況
- 問題が放置されていないか
- 自分が踏みそうなものが挙がっていないか
- 作者はどんな人か？
- 有名な gem の作者なら技術力ありそう(= ちゃんと動きそう)
ただ、「機能が少なく、あまり更新されない gem」とか「Issues は多いけど、他に代用もない phantomjs」みたいなのもあるので、上記だけでは判断できないこともある。
README を全部読む
はてなブログや Qiita などの記事は参考になるけど、「gem のアップデートに追従できていない」「インストール手順が中途半端」「一応動くけど、内容が微妙」みたいなのが多いです。 安易に信じると、未来の自分が死にます。
今までの経験上、信頼できるのは「ソースコード、次に README」です。英語が苦手でも、 README は一通り目を通した方が良いです。
依存関係を調べる
GitHub のリポジトリにある xxx.gemspec を読んで、依存関係がどのくらいあるかを調べる。
- 依存関係が多い
- 他 gem (特に Rails )のアップデートで苦労するかも
- 依存関係が少ない
- 他 gem へ移行することがあっても楽そう
ソースコードを読む
全部を読むのは時間かかるので、「バグに遭遇したとき、コードを読めそうか？直せるか？」の観点でざっと目を通します。
- ファイル数がどのくらいか
- 少ない場合は fork してメンテ(もしくは再実装)がしやすい
- メタプロがどのくらい使われているか
- rails_admin などは導入に覚悟が必要になってくる
- コードが読みやすいか
- 複雑なコードは直す気になりにくい
- デバッグ・修正も大変
- テストコードがあり、 CI が動いているか
- コードを直したときに、既存機能が壊れていないか確認できる
おまけ: 絶対にやったらダメ
はてなブログや Qiita の「おすすめ gem 10選」みたいなので公開されている gem を一気に Gemfile に入れるのは絶対ダメ。
問題が起きたときに「どの gem が原因か？」が分からなくなって大変なので、面倒でも1つずつ調べてから導入すべきです。
まとめ
ざっと gem を導入するときに気にしてることを書いてみました。何か参考になれば幸いです。
