说个自己这两年摸出来的笨办法。好多人读开源项目，clone下来对着源码从头啃，啃两天就放弃了——没目标感，不知道这段代码到底给谁用、边界在哪。我后来换了路子：不干读，先去给它补测试用例。

写测试这件事，逼着人把接口契约和边界条件先想明白。函数接什么、拒什么、异常怎么处理，搞不清楚就写不出能跑的断言。比起漫无目的翻代码，这种带目标的读，效率真不是一星半点。

挑活也有讲究。GitHub那些good first issue，筛带test、文档类的活儿，难度低、反馈快，PR合了还能混个contributor标签。顺手把示例和文档也补了，教别人的过程自己反而记得最牢，教学相长这话不是白说的。

从某种角度看，给开源出力不一定要写多牛的功能，把地基打稳也是在帮忙。

你写测试那一段，让我想起早年一个人在日本住的时候。那时也常陷进没着没落的阅读里，对着满架的书却不知从哪本下嘴，最后是靠每天抄一段喜欢的句子，才把心安顿下来。抄是笨办法，可笔尖落下去的那一刻，字句才真正进到身体里。
我觉得吧
你说的也是同一种道理。写测试像给对方递话，你得先听明白他在讲什么，边界在哪里、脾气如何，才敢接上下一句。比起一个人闷头啃源码，这种一来一回反而温柔，也难怪你引教学相长。

不过有一处我私心里不太苟同。挑 good first issue 是为了混个 contributor 标签、反馈快，这当然实在。可我最安静的收获，往往不在那个标签上。合了 PR 当然高兴，但更深的那层懂，常常发生在没人看见、也没人给你盖章的时刻

你这路子我年轻时候也无意中试过，挺管用的。只是得多留个心眼，挑带test、doc的活儿固然轻松，可要是总惦记着那个contributor标签，挑着挑着心思就挪到刷存在感上去了，地基是稳了，代码反倒没读进去。这事不急，让兴趣牵着走比让标签牵着强。

混contributor标签这招太真实了哈哈 我之前也眼红过那个小绿方块 不过clone完就睡着了

顺着你说的"带目标的读"，我倒想补一句。测试确实能逼你把接口契约和边界条件想明白，但"靠写测试就读懂了开源代码"这个说法，从某种角度看值得商榷。测试覆盖的是函数接什么、拒什么、异常怎么处理，而它为什么这么分层、模块之间怎么耦合，断言里推不出来。你提到效率"不是一星半点"，这个有具体的对照数据吗？我见过测试相当全的项目，真要搞懂作者为什么绕那道弯，最后还是得回去啃核心实现。