大家好，我是Z哥。
最近有位小伙伴求职遇到一些挫折，来找到我聊，其中有问到一个涉及到「阅读源码的必要性」的问题：“有很多场面试，面试官都有问到某个框架的某个功能是怎么实现的，难道真的要去看源码吗？但是感觉看源码除了面试有用，平时没啥用……”
我想可能有不少人都有一样的想法，所以我把我对阅读源码这件事的看法在这里和大家分享交流一下。
我曾经和一位同事聊天的时候打趣说，程序员可以分为4个层次。
1. 有阅读并吃透大型知名框架的能力
2. 能够知道并通过阅读框架源码来解决问题
3. 能够知道并通过找官方文档来掌握框架的使用
4. 需要有人手把手教或者自己踩过很多坑才能掌握一个框架的使用
这其实也体现了我对阅读源码这件事的看法。想成为厉害的程序员，阅读源码的能力必不可少，并且能够hold住的源码复杂度越高，水平越高。
我们程序员虽然每天都和代码打交道，但是大多数时候都是在「写」而不是「阅读」。唯有在接手一个新项目的时候，才会被逼着在短时间内阅读大量源码。毕竟，大多数情况下我们一直在固定的项目里“深耕细作”，阅读其它项目的源码，似乎对手头的项目没什么用。
但是在我看来，coding就好比写作，如果你想写出好文章，必然需要掌握很多语言组织上的技巧。比如，排比句、反复句等句式，比喻、拟人等修辞手法等等。这些其实就类似于coding中我们需要考虑的设计模式、算法这些东西。
在我们学生时代，老师会引导我们阅读大量的课外文章来提升这方面的能力，学习别人的写法，摘录别人的金句等等。
其实coding也是一样，如果你平时如果不多积累一些“美化”代码的“套路”，如何能写出优雅的代码呢？
所以通过阅读源码来提升你的编程能力，和阅读好文章提高自己的写作能力是一样的。
从这个逻辑也可以衍生一个新的逻辑，就是单凭自己顿悟、踩坑来提升编程技能的速度，必然比不过借助阅读别人源码来提升的速度。毕竟，参考、借鉴别人的东西可容易多了。你看，有哪个大文豪是不是阅读了大量的优质书籍？
回到本文的核心问题上，在Z哥看来，阅读源码的价值有很多，面试的作用只是一个短期价值。我认为它至少有以下5个价值。
/01 短期价值/
01 面试
正如前文提到的那位来找我咨询的同学，他也知道阅读源码对面试的作用是很大的。
因为有些实现细节如果我们只是会用，但不去看源码了解细节，其实就是所谓的“知其然而不知其所以然”。
比如，ArrayList 和 LinkedList 的区别？想要回答好这题，必须从源码入手，了解 ArrayList 和 LinkedList 底层实现。如果你没有阅读过源码的话，这道题肯定是回答不太好的或者回答的时候底气不足。
/02 长期价值/
01 在工作中更快地上手新项目
正如前文所说，每个程序员的职场生涯中，都无法避免“阅读源码”。因为你不可能一直在一个项目里工作，必然有机会接手很多陌生的项目。此时如何快速的了解项目的脉络、结构，以便自己快速的展开工作？这个时候，阅读源码能力高低就体现出来了。
虽说，如果上一位接手者还在职的话可以请教他，但是人家不可能真的像网传的「结对编程」图片那样，手把手解释给你，你说是吧？大部分时候还得看你自己的阅读源码能力。
▲图片来源于网络，版权归原作者所有
02 给自己创造用新技术的机会
很多技术人会抱怨工作中用不到新技术，一直在用老旧的技术。如果你寄希望于公司层面来推动一个新技术的运用，那就有点看缘分了，可能直到你离职也不一定会有这样的机会。
毕竟站在组织的角度来说，我现在项目跑得好好的，为什么要用新技术？新技术对我有什么好处，值得让我承担未知的风险？
但是如果你对某类技术其中之一的框架有源码级别的了解就不一样了。你可以借此主动推动运用某项新技术。因为你可以具体说出很多具有说服力的观点，
这个新技术到底好在哪里？
能够改善或者提升当前的系统的某几项能力？
为什么它可以提升这些能力？
它是怎么实现的？
如果我们要用它，需要提前对哪些知识进行储备？
……
况且，有时候组织层面不敢贸然使用新技术，可能也是担心没人能hold住这项新技术，万一出现什么问题无法及时解决怎么办？此时，如果他们发现这里有一位阅读过源码的伙计，这份担忧必然大大降低。
03 完善知识体系
那些大牛之所以能够在自己专攻的领域内无所不知，是他真的记忆力好吗？并不是，而是他的知识已经形成了体系框架。
完善体系框架的过程必然是你主动而为之，单凭工作中遇到问题时的百度、google是无法形成体系结构的，因为那些都是零散的碎片化知识。
如何快速的摄入大量原本就已经成体系化的知识？那些成熟的框架中就是啊，一个功能越庞大的框架，它所覆盖的知识面就越广，如果你能吃透它，你就可以快速扩充这方面的知识体系。这个过程简直就像是偷偷学了一本乾坤大挪移。
所以，阅读源码是一个加速你知识体系完善的有效方法。用不了多久，你也可以成为别人眼中的大牛。
04 学习别人的设计思路
靠自己领悟自然也能逐步成长，当然前提是你得能够「领悟」到什么。但是以这样的路线来成长，你会陷入以下两种境地。
自认为自己的设计很牛逼，而实际上……
觉得这样设计代码很变扭，但是又不知道有什么更好的方式。
如果你阅读过足够多的优秀源码，能够不断地吸取他人之长，这些情况自然就不会发生了。因为当你在看那些优秀的源码的时候，会有很多惊喜的过程。
“原来这里还可以这样来设计”、“对呀，这么设计不就搞定了么” 、“哇塞，这段代码设计的真精辟”，这些都是我在阅读那些优秀的源码时脑海中经常蹦出的词。
每当你觉得有收获到什么的时候，你可以将它们记录下来，并思考适用的场景。这样当你后续项目中遇到类似的场景，你就会想起“好像这里之前看到过一个精辟的设计，我去翻翻之前记录的代码案例。”
所谓“万事开头难”，阅读源码也是如此。因为当你阅读完第一个源码再去阅读下一个的时候，你自然而然地会带着批判或者说挑剔的眼光去阅读：为什么这个功能在我之前看的源码中是那样实现的，而在这里会是这样实现的？这其中的道理在哪里，哪种实现方式更优秀呢？通过这样的对比及探索，你会发现，自己的进步快得难以想象。
好了，总结一下。
这篇呢，Z哥和你分享了我对「阅读源码的必要性」这件事的看法。
我认为阅读源码和写作类似，相比自己琢磨、顿悟，更快的方式是通过借助、参考别人的思想成果来提升自己。当然，它的价值不仅仅用于面试，至少还有四个长期价值。
在工作中更快地上手新项目
给自己创造用新技术的机会
完善知识体系
学习别人的设计思路
不知道你对于阅读源码的态度是什么？欢迎在评论区分享你的看法。我后续打算再写一篇如何阅读源码，敬请期待。
推荐阅读：
学得越多，大脑越乱？
产品经理的「临界点」
原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」
