你别来问，自己看源码去

背景

下午和一位前辈讨论技术方案的时候，我就不停地在想，如果没有他，我就要花大量时间来看源码；如果新来了人，他也要花时间去看，大家花在看源码的时间真是多得可怕。

为什么看源码？

就我目前的工作经历和所见所闻，无数的论调都是：看教程不如看源码，程序员看源码成长快，周围的技术氛围也是：你别来问，自己看源码去。

一直都十分赞同这种观点，一方面，利己，看源码确实可以让自己跳出舒适区，学习别人的编码方式；另一方面，利人，不需要老是麻烦别人解释他们编写的代码。

但对于项目，没有足够的文档，新人为了开发新功能看源码来重新理解已有代码，算不算重复造轮子。
如果是，那这就真是最最耗时、最最坑的重复。

自己在反编译源码的时候，对于公司，绝对不利于项目快速推进；对于自己，个人收获也越来越小了，毕竟读代码的能力达到一定水平，读再多的代码也不会再有什么成长的空间。

所以，看源码似乎也没有那么好了。

为什么不降低看源码的难度？

一般来说，程序员都有一个思维：凡事化难为易。什么事，如果繁琐，困难，都很想尽办法让它变简单变快捷才是；但在熟悉项目上，想法却相反，认为要文档是偷懒，看源码才是优秀技术人员该做的事。

在别的事情上做得累，就一定要想办法降低难度；看源码这件事上，你看得累就是你的问题，而不是因为看源码这件事本身有问题。毕竟看源码的能力能体现出一个程序员的聪明程度，所以大家都默认这种困难的存在。

而且，这种要求自己看源码的心态还源自于可以以此来阻止别人要求自己给文档。我并不是真的认为看源码比看文档好，但是我真的不想写文档，所以你也别来问我要，我宁愿看你的源码，你有又什么理由不看我的呢？

文档要写，源码要看

从完成项目的角度来看待看源码，就会发现它极其不合理。

文档能大大提升熟悉项目的时间，当然是越多越好，一定要写。但是，现实的开发又不会允许大家有足够的时间来写全所有的文档，所以看源码的能力还是要有的。