理想的には共通化できる機能は切り出してgemにすることだけれど、次の理由から標記のパターンもなくはないのかも、と思いつつある。
- 外部gemより、同じプロジェクトのlibに転がっていた方が、正直トラブルがあったときに追いやすい
- 数行で実装できるものを外部gemにするのは大仰な感想を受ける
- 現実問題、まだbundlerがそこまで賢くない時がある。また、gemであると依存関係を解決できない場合もある
- 外部gemのオーナーは我々ではなくそのgemの開発者である。よって必要十分な機能をgemが有しているとは限らない。要らないコードが邪魔をするパターンすらあり得る。といいつつむやみなforkはやっぱり不格好
正直、次に挙げる程度の機能はプロジェクトに入っていた方が小回りが利くね、という気がしている。実装のコードを思い浮かべてほしい。ホントに数行だし、ActiveSupport::Concernを使えば分かりやすく書けるはず。
- ページネーション
- 理論削除
- フレンドリーID
そうすると、たとえば社内での共通化が問題になるんだけれど、一つの案としてはgemより小さい単位のsnippetとして管理して、必要に応じてダウンロードさせて使う。
bower/yeomanみたいにスクリプト自体を落としてくれてホストする、みたいな。あとPadrinoのplugin。 padrino plugin omniauth したら omniauth に対応したコードの変更が入る。この場合はコードの更新性が問題になるけど…… ディレクトリを分けるなどで対応？
あと、テストを自分で書くことになる。gemであれば（ちゃんとしたプロジェクトは）その辺は気を回してくれるので……。
なんにせよ、Gemfileの肥大化は何ともならんのかな〜と思っている。
反論を受けて曲げるかもしれない程度の意見です。
