複数人でのRuby/Rails開発で、Gemを利用するかどうかの判断はどのように行なうべき？

Question

個人的にRuby/Railsを勉強し始めたのですが、インターネットの記事を見ると問題に対してGemの利用を推奨している記事を多く見ます。

個人的には外部ライブラリを利用し過ぎると、色々と問題があるように考えているのですが、実務でGemを利用することは一般的に行われているのでしょうか。

また、開発チームの方針にもよるのでしょうが、Gemを利用するのであれば、チーム内では「Gem入れました」で済むものなのでしょうか。
それとも、チーム内でGemを入れるかどうかの相談をしたり、Gemのソースコードを読み込んで問題ないかどうか判断する、などの作業を都度行うのでしょうか。

このあたり、皆さんがどのように進めているか知りたいです。

Gemの入れ過ぎた場合の問題としては、例えば

• Gemの仕様が絡んでアプリ自体のカスタマイズがしにくくなる。
• Ruby/Railsのバージョンアップの際にそれぞれのGemが新バージョンに対応しているかどうか確認しなければならない。
• Gemの仕様に設計を合わせなければならない。
• Gemが使えなくなった場合にGemに合わせた仕様に意味がなくなり、後から来た人にとっては意味不明な仕様に見える可能性がある（設計の見直しが必要になる）。

などがあるかと思います。

学習を初めて間もないため、上記にはそもそも問題とならないものがあるかもしれませんので、その場合はご指摘ください。

よろしくお願いします。

Comments

[maisumakun]

まず、Rails自体もGemの1つですが、そのあたりについてはどのようにお考えでしょうか。

[segawan]

ご質問ありがとうございます。
簡単な機能のアプリケーションの場合、Railsに従えばかなりのショートカットになると思うので問題ないかと思いますが、複雑な機能の場合は問題ないかどうか検討する必要はある、という考えです。

私としてはGemの利用自体は大した問題とは考えておらず、Gemを「濫用」した場合に設計の可動域が絞られていき、保守性が悪くなるのでは、と考えています。

Rails（フレームワーク）Gemにおいては、「設計の可動域が絞られる」という状態は機能の一環と考えています。（絞ることによりコードの一貫性を高めるものだと思っています）
ただ、ある程度複雑なアプリケーションの場合はRailsも邪魔になることはあるだろうと考えています。

Answer 1

機能改変系GemはNG、機能追加系GemはOKという観点もあると思います

論理削除gemを1年ほど保守してみて。重大な欠点にやっと気づいたポエム という記事が参考になります

ActiveRecordの削除に関わる部分を完全に置き換えたkakurenboが生まれたわけですが、railsのパッチアップデートですら動かなくなることがありました。マイナーアップデートならほぼ確実。メジャーアップデートならacts_as_paranoidのようにプロダクトが廃れるのではないかとすら思います。

機能改変系は設問で懸念されているリスクが高くなります

悩んだ末に私が出した答えがこれです。destroyのオーバーライドをやめ、素直にsoft_destroyというメソッドを設けることです
gem kakurenbo-puti
思い切って呪縛を立ち切れたgemです。コアファイルは70行以下です。
使っているメソッドもrailsのレールを脱線していないメソッドばかりなので、何も修正せずにメジャーアップデート対応できる気すらします！

単純な機能追加ならそれらのリスクは低くなります

Comments

[segawan]

ご回答ありがとうございます。
標準機能をオーバーライドするGemって怖すぎますね…

挙げて頂いた例では呼び出すメソッドの時点で「destroy」が改変されているであろうことが分かるのでいいですが、表層的でないメソッドをオーバーライドされているかもしれない、と考えると、やはり実務レベルではGemのソースコードを解析する必要がありそうですね。

[Ighrs]

少なくともGemの説明文は読み込むべきだと思います
流石に説明なく標準機能をオーバーライドするようなGemは流行らないですし

[segawan]

確かに流行り（多くの人たちに認められている）ものについては、判断基準が微妙になることもありますが、一つの指標にはできそうですね。
ありがとうございます。

Answer 2

回答になりますかどうか。

gem はごく一般にいうソフトウェアライブラリと同等に見立てたらよいと考えます。バージョンが上がれば、それに基づいて構築したアプリケーションには影響します。当方の全般的なアプリ開発経験として、ライブラリは開発時および運用後も、滅多やたらとバージョンアップすべきではなく固定することが普通かと思います。そうでないと開発すらままなりませんし、例えばテスト工程にてライブラリが変わったりしたらそれまでのテストが無価値になってしまいます。

Rails には Gemfile にて、各 gem のバージョンを固定する機能性があります。また Ruby のバージョンも固定できます。Rails の開発実務経験はありませんが、想像ではバージョンを固定するものではないでしょうか。特に gem は一般的なライブラリに比べて、頻繁にバージョンアップするようにも見受けますので、ま正直にバージョンアップに追随していたら大変なことにもなります。

Rails 自体が複数 gem の合体ですし、そこにどれだけ gem を加えたら濫用になるのかは、gem の内容次第かと思います。当然 gem が多くて、そこへの依存リスクがあるわけですが、その gem から得られる機能性・利便性との兼ね合いでの評価となると思います。ただ間違っても、無評価の gem を「新しいのが出たから入れまーす」などという状況は有り得ません。新種の gem は手を出すのが難しく試行の上、慎重に採用検討することでしょうし、十分こなれた gem であれば積極的に採用するということもあるのではないでしょうか。

追記
Rails はフレームワークですから、これを採用した時点で、ある程度の機能制約を受けると思います。ただ、世に公開されている "便利gem" 類は、このフレームワーク上に構築されており、今言った機能制約とは次元の違う、その gem 固有の機能制約となるはずです。そして "便利gem" は、こんな機能があれば便利、誰もがこんな機能を求めるであろう、というところから出来上がっており、そこに機能実現困難な仕様があるなら、作り変えればよいとなります。つまり "便利gem" は開発工期短縮の側面もになっています。

Comments

[segawan]

ご回答ありがとうございます。

> 当方の全般的なアプリ開発経験として、ライブラリは開発時および運用後も、滅多やたらとバージョンアップすべきではなく固定することが普通かと思います。

私のイメージでは、セキュリティを考慮してOSをアップデートするかのように、サーバーサイドのライブラリも頻繁にアップデートするものかと思いこんでおりました。
経験上でのお話、ということですが参考になります。ありがとうございます。

フレームワークgemのように便利gemも含めて設計を合わせる、というスタンスなんですね。

ちなみにgemの評価方法についてですが、matsuandさんの現場ではgemのソースコード解析などは行われたりするのでしょうか。例えば「暗号化を行うgem」について暗号化の安全性を確かめるためにgemの資料を作成したりするのかが気になっています。
また実務において、「チーム内の誰も使ったことはないがgit-hub上のstarや更新履歴などの活発度合から使っても問題ない」と判断されたりはしますか？

[matsuand]

サーバーサイドのライブラリも頻繁にアップデート、のくだり、セキュリティフィックスはまた別の話で、こちらは出来る限り適用すべきところと思います。また回答内にあるように、railsの実務経験はありませんので、いくつかのご質問には答えかねます。あしからず。

[segawan]

すみません、詳しくお話頂いたのでRailsではなくRubyでの実務経験があるものかと勘違いしていました。

セキュリティフィックスについても作業コストとの兼ね合いがありそうですね。
参考にさせて頂きます、ありがとうございます。