GEM 那么多，这个不好推荐吧。主要看你是是想达成什么目标，带着目的和问题去看，会更有针对性。搞 Rails 的话，看看它 相关的 GEM

另外我准备看看这个 https://github.com/dry-rb，感觉蛮有意思的。

你先说你知道的 gem 有哪些呀

目的已更新

额，我知道的 gem 不多，就是一些常用的 gem，比如 rails、device、kaminari、rest-client 和 nokogiri 等等，这里主要是想找那种比较容易读的 gem 或者功能片段，锻炼阅读源码的能力

我觉得应该选一个你深度使用过的 Gem，先了解它对外提供的所有接口，使用的很熟练后，再去看会更好些。

阅读源码还是带着问题从一个较小的切入点（比如某个函数的实现）开始去读更好些，专门从“头”阅读，收益会比较有限。

额，大佬，请恕我不是很能赞成这个观点，因为当 gem 代码的功能很多时，功能之间会有很多交错，各种代理 (我承认有人可以在众多代码中轻易找到主线，但我也相信有一部人不行)，一旦层级多一点，就很容易找不到主线，也很容易被与主线关联不大的代码吸引，所以才希望先找比较简单的 gem，这样即使有一点与主线无关的代码，也不会很影响对源码的理解。

虽然想回答楼主提问，但仔细想想我找不到合适的推荐。

一般阅读源码出于这样的目的：

1. 发现 bug 了，查找是上游问题还是自己问题。
2. 自己实现一个功能遇到瓶颈，参考同类实现。
3. 有几个类似的 gem，根据源码哪个实现比较优雅来选择。

如果楼主没有遇到我同样的问题，推荐了也学不到什么。

额，感谢大佬的回答，我再努力找找，感觉没得进步就会被淘汰，ruby 也终究逃不脱被卷的命运

通过对这些 Gem 的功能片段的阅读，可以让源码新手能从易到难，循序渐进的去培养阅读源码的能力。

这是个很理想的想法。多年前的我也有些这样的想法，想着先读完一个难度为 1 的源码，再去读难度为 2 的源码，逐渐继续，那么就能读下来难度为 100 的源码。但现实是复杂的，源码并不会标注自己是难度 1 还是难度 2，"难易"的评判是一个小马过河式的问题。

我跟 5 楼和 7 的看法一样，真要读 gem 源码时，一般是在使用 gem 时产生了些疑惑，或者需要魔改 gem。把“阅读源码”本身当作阅读源码的目的，我自己的结果是，容易失去重心，最终只学到些没见过的语法糖和 API。

如果楼主非要读 gem 源码，在掌握调试技能和熟悉 gem 公开 api 前提下，拉取 gem 的最初版本代码，配合他的单元测试，顺着测试单步调试，再难的 gem 都能看下来。当然，如果 gem 的单测写得不好，很可能说明没啥阅读价值。。。。

额，看来由易到难这条路确实很难走，我再试试吧，不行就回来

慢慢研究 Rails API 文档，收益会比阅读源代码更好。

然后是，在 Rails API 之前，甚至应该认真读完 Rails Guides，那个也有很多技术细节的。

好的，谢谢大佬指点，说起来，好像除了刚入门 rails 的时候，基本上很少看 Rails Guides 了，确实是个知识盲点，受教了

我读过一些，目前印象最深的是whenever, 这个是我第一个感觉"读懂了"的源码

过程中有这几点收获

1. 知道了一个 gem 的目录结构组织方式
2. 知道了怎么找 gem 的入口 (一般是 bin 下的命令行工具), 或者是根据需要解决的问题找到对应的入口
3. 学到了一点写命令行工具的套路optparse
4. 慢慢能抓到代码里的主线了，暂时忽略细枝末节，不会总是迷失在代码跳转中
5. 掌握了用编辑器 (sublime) 读代码的技巧 (goto-definition/go-back/bookmark/code-folding/code-navigation)
6. 通过读 whenever 源码了解到IO.popen的使用，从而解开了困扰我很久的疑惑："whenever 是怎么写入 crontab 的？", 增强了读代码的信心
7. 好多 gem 都带有测试用例，这也可以是读代码的入口; 在模仿着写测试 (但是目前写得不好 )

很认同前面大佬说的，得有目的地去读才行，不然很容易迷失。