说个自己这两年摸出来的笨办法。好多人读开源项目，clone下来对着源码从头啃，啃两天就放弃了——没目标感，不知道这段代码到底给谁用、边界在哪。我后来换了路子：不干读，先去给它补测试用例。
写测试这件事，逼着人把接口契约和边界条件先想明白。函数接什么、拒什么、异常怎么处理，搞不清楚就写不出能跑的断言。比起漫无目的翻代码，这种带目标的读，效率真不是一星半点。
挑活也有讲究。GitHub那些good first issue，筛带test、文档类的活儿，难度低、反馈快，PR合了还能混个contributor标签。顺手把示例和文档也补了，教别人的过程自己反而记得最牢，教学相长这话不是白说的。
从某种角度看，给开源出力不一定要写多牛的功能，把地基打稳也是在帮忙。
你写测试那一段，让我想起早年一个人在日本住的时候。那时也常陷进没着没落的阅读里，对着满架的书却不知从哪本下嘴，最后是靠每天抄一段喜欢的句子，才把心安顿下来。抄是笨办法，可笔尖落下去的那一刻，字句才真正进到身体里。
我觉得吧
你说的也是同一种道理。写测试像给对方递话，你得先听明白他在讲什么，边界在哪里、脾气如何，才敢接上下一句。比起一个人闷头啃源码，这种一来一回反而温柔，也难怪你引教学相长。
不过有一处我私心里不太苟同。挑 good first issue 是为了混个 contributor 标签、反馈快，这当然实在。可我最安静的收获，往往不在那个标签上。合了 PR 当然高兴，但更深的那层懂，常常发生在没人看见、也没人给你盖章的时刻
你这路子我年轻时候也无意中试过，挺管用的。只是得多留个心眼，挑带test、doc的活儿固然轻松，可要是总惦记着那个contributor标签，挑着挑着心思就挪到刷存在感上去了，地基是稳了，代码反倒没读进去。这事不急，让兴趣牵着走比让标签牵着强。
混contributor标签这招太真实了哈哈 我之前也眼红过那个小绿方块 不过clone完就睡着了
顺着你说的"带目标的读"，我倒想补一句。测试确实能逼你把接口契约和边界条件想明白，但"靠写测试就读懂了开源代码"这个说法，从某种角度看值得商榷。测试覆盖的是函数接什么、拒什么、异常怎么处理，而它为什么这么分层、模块之间怎么耦合，断言里推不出来。你提到效率"不是一星半点"，这个有具体的对照数据吗？我见过测试相当全的项目，真要搞懂作者为什么绕那道弯，最后还是得回去啃核心实现。
我也有过这种感觉，对着源码从头啃真的会困。你这个法子好，先把边界想明白再读，比干读踏实多了。
补测试逼着人把边界想清楚，这点是真见效。我自己的体会反过来也成立：你以为读明白了，一上手写断言立刻露馅，哪个分支没覆盖、哪个异常没定义，藏不住。
不过有个更省时间的路子帖子没提：先读项目现有的测试套件。维护者把什么当关键路径、哪些输入算边界，全写在那堆 case 里。等于有人先帮你划了重点，顺着读源码比裸读目标感强太多。写自己的测试是第二步，不是第一步。
good first issue 那思路没问题，加个筛选条件更稳：带 test 标签的活儿里，有一大半是给 getter 补无意义断言，合了 PR 也就混个绿勾。真值钱的是"复现某个边界 bug"的题，写一条能 fail 的用例比十条正常路径都有用。挑的时候看描述里有没有具体输入和报错，光写"improve coverage"的基本凑数。
你说的"把地基打稳也是在帮忙"我接。但我后来发现 contributor 标签本身填不满什么——合了十个 PR 回头看，留在脑子里的不是那个绿勾，是有次为了测一个并发边界，硬把整个模块的数据流梳理了一遍。地基打稳，受益的是自己理解的速度。
补文档那块你漏了个隐性收益：写给别人看的时候，被迫把"我以为懂了"换成"我能讲清楚"，这步最杀虚假的熟悉感。
等等，你说的筛good first issue里带test的活儿，我怎么听说的版本不太一样。我听说好些项目反而是文档和测试类的PR最没人理，maintainer天天盯着功能开发，你递个补测试上去，三个月没review也是常事。
不过"混个contributor标签"这点倒被你点破了，我观察过，现在真有一拨人专门扫这种标签刷简历，合了俩PR就敢写开源贡献者。但像你说的从补测试顺手摸透代码，这种人反而留得下来。你那几个PR投的什么项目啊，个人小库还是大厂背书的正经repo？
这招我也在用，但补个盲区：照着代码现状写的测试，特别容易把现存的bug一起固化成"正确行为" 我前阵子读一个解析库，先补测试发现某函数对越界输入居然返回0而不是报错，我还以为是feature，断言就写成expect(foo(-1)).toBe(0)，结果翻issue才知道那是三年的老bug，合进去的PR反而把错误行为锁死了。所以动手写断言前，最好先瞄一眼对应issue和git blame，分清现在是"设计如此"还是"烂摊子没人收"。
good first issue那块，楼主说反馈快、能混contributor标签，sounds good，但得挑。有些repo的good first issue是bot批量打的，半年没review，你PR石沉大海反而打击信心。我一般先看这仓库最近一个月merged的PR密度和maintainer回issue的速度，再决定下不下手。光为了个绿标，性价比真的不高，卷也该卷在刀刃上。哈哈突然想到
教学相长那句我特别信。诶私货一条：给文档补example时我习惯写成能直接copy跑的snippet，比干巴巴的API列表好懂太多，别人问起来自己也省得重新翻。读代码目的不是读，是能用能改，这点完全同意。
你们碰到过测试写完发现整个模块设计就不合理的吗，那才叫头秃
补测试确实爽，比干啃源码快多了~不过文档类PR容易撞车哈哈
你这"混个contributor标签"说得也太实诚了，论坛上多少人是冲着那行小字去的，偏要包装成"为爱发电"。不过说真的，写测试倒逼读代码这招我服，比对着几千行源码干瞪眼强太多。我之前也试过clone下来硬啃，啃到第三天连main函数在哪都忘了，离谱。就冲这点，你这笨办法一点都不笨。
contributor标签这个动机我直接笑出声，太真实了，谁还没点虚荣心呢。不过你这法子确实比干啃源码靠谱，我之前clone个大项目，第三天就躺平刷短视频去了，README都没翻完。
太！
不过想抬个杠：good first issue里的test活儿，有时候比想象中阴间。我见过那种描述就一句"add more tests"，点进去发现得先摸清整个模块的隐藏边界，写完比写功能还累。当然累完确实记得牢，这点你没骗人。6
话说你一般挑多大的项目练手？笑死巨无霸repo和小library，体验差得挺远的吧。
你这个’带目标的读’戳到点子上了。我平时不碰代码，但学任何东西都一个理——没个具体目标硬啃，两天就泄气。
'把地基打稳也是在帮忙’这话我服。最不起眼、最没人抢的活儿往往最磨人，但地基松了上面全白搭。简单说你先补测试再读源码，本质就是把’看懂’拆成能下手的小步骤，比对着屏幕干瞪眼强太多。