看同类型项目用的什么。 看 gem 中得依赖 gem 看 gem 的文档和 star，fork 看 gem 代码 看 gem 测试用例 看是不是 fork 别人的，自己有改动，如果是，最好用原始出处。 看兼容的版本

感觉，研究 gem 中的 gem，有点像是拆开旺旺大礼包，真不知道里面又放了什么。不过看过很多 gem 之后，收获蛮大的。

https://www.ruby-toolbox.com

Google 搜索，使用最著名的

https://www.ruby-toolbox.com +1

不知道大家有没有翻看自己用的 Gem 的源码的习惯？

小白的时候，我总是喜欢通过找 Gem 来解决各种需求，后来一个项目上三五十个，甚至百八十个 gems 都有... 项目后期，尤其是升级的时候苦不堪言。

长期经验总结下来，除非某个 gem 能够完美的匹配你的需求，或多或少都有可能引入新的问题。后来我也是通过 http://www.ruby-toolbox.com 来找 gem，但是除非万不得已，我尽量不引入一个外部 gem，至少也要跟同事们讨论一下是不是一定有引入某个 gem 的必要。

在引入新的 Gem 之前，我一般会自己大致过一遍源码，因为通常 Gem 的 Readme 只介绍如何使用，不会介绍 Gem 的内部原理，或者实现方法，更不会告诉你有没有什么坑之类的。翻看一个 Gem 的源码，通常十几分钟，半个小时，至多不超过一小时就可以做到心中有数，用不用就更有把握了。

有的时候甚至不必要真的引入一个 Gem，自己从 Gem 中抽离一段代码，然后简单封装一下反而更契合自己的需求，而且也更加环保。有的时候 Gem 的实现太过复杂晦涩，总有一天会找你的麻烦，比如 Devise 这个东西，看似强大，实则应该能避免就尽量避免使用...... 后话了。

#5 楼 @lgn21st 严重赞同 使用每一个 gem 时，尽量做到把它的源码大致过一遍，以此来评估这个 gem 适不适， 当这 gem 出现问题时，通过源码通常是最高效解决的方法。

不过一遍 gem 源码真不敢用，死都不知道怎么死的。血的教训。 如果只有一个源代码文件的 gem，直接拉进项目里面，减少 gem 的 overhead，以及出错概率。

#5 楼 @lgn21st 想看这个后话...

#5 楼 @lgn21st #6 楼 @vincent #7 楼 @linjunhalida

难道你们连 capybara, rspec, factory_girl 之类的源码都要看过才敢使用吗？

还是一些和业务关联比较大的，比如用户系统（devise），点赞（make_voteable）之类的

#9 楼 @kkeys 我还真没有看过 capybara ,可能跟我用的比较少有关吧。

#11 楼 @lgn21st 诶，我好奇了

如果你很少用 capybara 的话， 在 acceptance test 里面，对于点击 link，填写表单，查看页面内容这些操作，你都是怎么进行的

还是你很少写 acceptance test？

#9 楼 @kkeys 测试用的 gem 不会那么关注。生产用的 gem 还是要看过一遍的。

#12 楼 @kkeys

Cucumber, Jasmine，程序员人肉，QA 人肉

#12 楼 @kkeys 的确是主观上很少写，能不写我几乎不写 acceptance test, 我个人认为维护 acceptance test 给我带来的价值不高，这个跟我们的项目类型特点，开发环境，以及开发习惯有关。另外我不喜欢类似 capybara-webkit 这样的需要一个 driver 实现开启一个浏览器跑测试的方式，测试效率和结果都无法让我满意。