Gemの選定基準
Gemを使うべきかどうか
第一選択肢はGemを使わないことである。Gemを追加するということは、中身を十分に把握していないコードを組み込み、セキュリティアップデートや非互換な改修に追従するコストを払うことを選ぶことを意味する。
また、Gemの提供する機能が本当に必要な機能なのか考えなければならない。「ちょっとおしゃれなコード」が書けるようになるだけのGemは必要がないはずである。PORO（ライブラリなどに依存しないプレーンなコード）で記述が可能なものはPOROで済ませるべきである。
本当に追加するべき機能をGemが有していてリスクやコストを加味しても、自分でコードを書くよりGemを利用した方が良さそうな場合にようやくGemを使う選択肢がでてくる。
選定基準
将来性
一言でいえば、開発が活発で利用者が多いかどうか。
- GitHubのStar数が多い
- RubyGemsでの累計ダウンロード数が多い
- RubyGemsでの現行バージョンのダウンロード数が多い
- 最終コミット日が近い
- 最終リリース日が近い
- issueの最終クローズ日が近い
- pull requestの最終クローズ日が近い
The Ruby Toolboxを利用する方法もある。
注意点としては、GitHubのリポジトリを引っ越している場合はStar数がリセットされてしまう。妙にStar数が少ない場合は古いリポジトリが存在しないか確認した方が良い。
情報量
一言でいえば、コードを読まずに得られる情報が多いかどうか。
- ドキュメントの量が多い
- Qiitaなどで利用例や解説のエントリが十分にある
開発容易性
一言でいえば、内部構造を意識せずに機能を使えるかどうか。
- deviseのようなカスタマイズが前提のパッケージタイプのGemではない
- カスタマイズが不要なら問題はない
- Kaminariのようにカスタマイズが簡単な場合も問題はない
- sorceryのような自分で組み立てる前提のライブラリタイプのGemである
調査容易性
一言でいえば、内部構造を調べなければならない時に簡単に調査できるかどうか。
- ディレクトリ構造の意図の掴みやすい
- アーキテクチャがイメージしやすい
- 適当なところから読み始めて自分が今なんの処理を読んでいるのか、すぐに察しがつくかどうか
- 他のGemへの依存が少ない
- 特に複雑な機能を提供するGemに依存していない
- 特に核となる機能が他のGemに依存していない
メンテナンス可能性
一言でいえば、Gemが放棄されてしまった場合などに自分たちで面倒が見れるかどうか。
- 調査容易性を満たしている
- コード量が多くない
- 機能拡張の仕組みがある
- モンキーパッチやオーバーライドが容易にできる
優先順位
簡単なイメージとして点数づけした表。
| 採用度 | 将来性 | 情報量 | 開発容易性 | 調査容易性 | メンテナンス可能性 |
|---|---|---|---|---|---|
| 0 | 0 | - | - | - | - |
| 50 | 10 | - | - | - | 80 |
| 80 | 50 | 30 | 80 | 80 | - |
| 30 | 100 | 80 | 30 | 10 | - |
開発容易性と調査容易性の重要度が高い。
情報量は調査初期段階では判断材料として加味しうるが、最終的な判断での重要度は高くない。
将来性が低い場合はメンテナンス可能性とのバランスになるが、将来性が高くても加点要素にはならない。