“源码” 应该怎么读

其实 “读源码” 并不是从现在才开始内卷,而是早就如此了。

我还清楚的记得当时为了学习 jQuery 的 ”源码“ 把 jquery@1.4.3 打印下来了,很厚的一沓。


读了以后呢,在各种考察 ”源码“ 的环节,变得更有自信了,对答如流显得非常专业。

然而实际使用中反而发现,关于 “如何使用 jQuery” 居然 还不如多看几遍文档更有帮助。


于是就在那时我反思了以下几个问题:

  • 阅读 “源码” 对学会使用某个软件工具来说,到底有没有帮助

  • 我为什么要读 “源码”,想达成什么效果

  • 开源优秀代码库的 “源码”,跟我们自己项目中的 “代码”,有什么不同


要澄清以上几个问题,其实并不是那么容易,且听我仔细分析。

“源码” 是什么

我不明白为什么,人们喜欢管 公司外 别人写的代码叫做 “源码”,而管 自己同事 写的代码叫做 “代码”。

它们不都是 “源代码”(source code)吗?我还专门查了一下 维基百科,

In computing, source code is any collection of code, with or without comments, written using a human-readable programming language, usually as plain text.

The source code is often transformed by an assembler or compiler into binary machine code that can be executed by the computer.


所以同事写的代码应该也是 “源码”,可为什么人们经常以读过 “外部源码” 为荣呢?

花时间读了一堆 “外部源码” 却连 “自己负责项目的代码” 都没系统的读过,不觉得这很有问题么?


我自己也没读过那么多的 “外部源码”,本来也没有资格 “教” 别人怎么读 “源码”,

印象比较深的也只有 jquery@1.4.3,webpack@4.20.2 和 typescript@3.7.3。


但是,自从意识到 项目代码也是 “源码” 以来,心情就变得更加务实了。

先把 同事的代码 读懂了再说,先理解清 内部项目 的业务逻辑。


Tips:“源码” 就在我们身边

“读源码” 的功效

我意识到 “读源码” 这个词被烘托的特别高大上,但只要一把 “源码” 换成 “代码” 就立刻变得索然无味了。请看下面两句话,

他在读源码

他在读代码


  • “读代码” 这种说法,显得读的这个人水平特别低,他应该上来就能写,怎么还得花时间读?

  • “读源码” 这种说法,显得读的人 “精益求精”,对技术细节或原理有着孜孜不倦的追求。


为什么会有这种不一样的感觉呢?这就是我们对 “品牌营销” 洗脑了。


我对汽车不是特别了解,但为了说明问题,我在想在这里举个不是特别恰当的例子。

百度百科上介绍,大众集团 是当前世界十大汽车公司之一,大众汽车 是大众集团旗下的人们耳熟能详的汽车品牌,


集团目前拥有10大著名汽车品牌:

大众汽车(德国)、奥迪(德国)、兰博基尼(意大利)、宾利(英国)、布加迪(法国)、

西雅特(西班牙)、斯柯达(捷克)、大众汽车商用车(德国)、保时捷(德国)斯堪尼亚(瑞典)。

什么?奥迪、兰博基尼、宾利 …… 它们也是大众集团的汽车?我不懂啊,别问我。


上面这个问题的答案其实不重要,可是大脑认为 某些汽车是 “名车” 的这种认知 让人后怕,为什么我们的大脑中会存在这样的默认选项?


Tips:“源码” 也许没有那么 “包治百病”,“人参果” 也不会让人长生不老。

读 “源码” 的预期效果

现在我们知道 “源码” 的局限性了,它跟 “代码” 其实没有什么不同。那么还有没有必要 “读源码”(读代码)呢?我认为很多情况下是不需要的。


  • 从源代码中很难看出它所实现的功能该如何使用

  • 从源代码中很难看出作者的设计思路

  • 大部分代码都写的很烂,能跑/能解决问题/勉强能看 足矣


如上文分析所示,如果真的想看 “代码”,我觉得看一下 “项目中的代码” 就够了,除非遇到了 “三方库”(公司外的依赖) 本身的问题。


所以 “读源码” 的问题就转换成了,

  • 正视 “读源码”(读代码)这件事

  • 不畏惧 “读源码”,敢读、会读、能读

  • 合理分配时间,读最值得阅读的那些代码


Tips:做计划之前,要管理好自己的预期

读 “源码” 的战术策略

好了,如果我们真的遇到了一个不得已的场景,或者茶余饭后实在百无聊赖,就想读一个外部仓库的代码,我们应该怎么做?


  • 不要上来就读最新版,而是找到相应代码的一个快照版本,尽量锁定它的所有依赖,再进行阅读

  • 阅读的过程中,保持记录的习惯,最好是一边读一边写文档。相信我,读完以后再写文档会非常的麻烦

  • 要练习 “读” 的能力,就不要看网上那些二三手的资料,完全靠自己读下去;当然如果是为了看懂代码写的到底是什么意思,就另说


当然,有很多人 “读源码” 仅仅是为了应付考试/面试,这就无能为力了,因为我没有这么准备过。让我做一件仅仅是为了 “装懂” 而做的事情,我坚持不下去,我们应该是为了 “弄懂”。


“读源码”(读代码)是一件非常耗时耗力的过程,我只能拿前端领域的问题来说,当前很多代码库都挺复杂的(依赖比较多),动辄也得需要 (4小时/天) * (1~2 月) 才能读完。

当我们对某个代码库进行系统化的学习之后,很容易是得不偿失的


  • 也许还不如突击看一下网上那些二三手资料,让人 “看起来” 更懂(如果以此为 “得失” 的话,要慎重考虑这一点)

  • 系统的读一遍代码之后,对于整体脉络的理解程度,会因人而异;如果你读完一本小说,可以清晰的讲清楚主线剧情,那么恭喜你,你读完 “源码” 之后也能,否则,emmm……

  • 读完代码库的源码,不会变成这个领域的专家,更不会用到它,只是知道它是怎样实现的而已;你无意中掌握了造轮船的能力,但是实际你不需要造轮船,你需要的是一张船票,就算需要造也没那么多钱造它


Tips:读代码要讲究策略,目标清晰、掷地有声

结语

这篇文章看起来并不像一篇 煽动 大家读源码的 “鸡血文”,更像是一篇提醒文。

”源码“ 不是灵丹妙药,”读源码“ 也不是一种罕见的能力。

我们手头上就有 ”源码“,谁都会 ”读“。


但有些事情只有亲身去做了才有感触,正所谓 ”纸上得来终觉浅,绝知此事要躬行“。

所以不妨行动起来,技术成长过程中的酸甜苦辣,还终得亲自尝一尝才行。