题目是陈皓回答的，来自知乎。我只是希望更多的人看到。

Jeff Atwood说过这么一句话：“Code Tells You How, Comments Tell You Why”.

其实，Jeff这句话并不准确，另外，我把其扩展一下——

代 码 => What, How & Details
文档/书 => What, How & Why

可见，代码并不会告诉你 Why，看代码只能靠猜测或推导来估计Why，是揣测，不准确，所以会有很多误解。而且，我们每个人都知道，Why 这个东西是让你一通百通的东西，也是让人醍醐灌顶的东西。（这也是楼主为什么喜欢看书的原因，我也是）

但是，代码会告诉你细节，这是书和文档不能给你的，细节是魔鬼，细节决定成败，这样的话我们不但听过很多了，我们做技术的也应该体会过很多了。当然，我们也要承认，这些代码细节给人带来的快感毕竟不如知道Why后的快感大（至少对我是这样的）

书和文档是人对人说的话，代码是人对机器说的话。

所以，

1. 如果你想知道人为什么要这么搞，那么你应该去看书，看文档（就像Effective C++、Code Complete、Design Pattern、Thinking in Java等等这样的书）
2. 如果你要知道让机器干了什么？那你应该看代码！(就像Linus去看zlib的代码来找性能问题)

因此，我认为都比较重要，关键看你的目的是什么了。

• 如果，你想要了解一种思想，一种方法，一种原理，一种思路，一种经验，恐怕，读书和读文档会更有效率一些，因为其中应该会有作者的思路的描述。比如像Effective C++之类的书，里面有很多对不同用法和设计的推敲，像TCP/IP详解里面也会对TCP算法的好坏的比较……这些思维方式能让你对技术的把握力更强。光看代码很难达到这种级别。（现在你知道什么样的书是好书了吧 ;-)）

• 如果，你想了解的就是具体细节，比如：某协程的实现，某个模块的性能，某个算法的实现。那么，你还是要去读代码的。因为代码中会有更具体的处理（尤其是对于edge case或是一些代码技巧的东西）

另外，看看下面的几个现像，你可以自己比较一下：

• 很多时候，我们去读代码，那是因为没有文档，或是文档写得太差。
• 很多时候，你在google, stackoverflow, github过后，你会发现，你掌握的知识就是一块一块的碎片，即不系统，也不结构化，更别说融汇贯通了。你会觉得你需要好好地读一本书，系统地掌握知识，这种感觉你一定很强烈吧。
• 很多时候，在你去读别人代码的时候，你会因为基础知识或是原理不懂，或是你不知道为什么的情况下，你要么完全读不懂代码，要么就是会误解代码。（比如：如果你没有C语言和TCP原理的基础，你根本读不懂linux下TCP的相关代码的。我们因为误解代码用意而去修改代码造成的故障还少吗？）
• 很多时候，看到一个算法时或是一个设计时，比如Paxos这样的，你是不是会有想去看一下这个算法的实现代码是什么样的？如何才能实现的好？（但是如果你没看过Paxos的算法思想，我不认为你光看代码实现，就能收获到Paxos的思想）
• 很多时候，当你写代码的时候，你能感觉得到自己写的代码有点别扭，怎么写都别扭，这个时候，你也会有想去看别人的代码是怎么实现的冲动。
• …… ……

从代码中收获得大，还是从书中收获的大，不同的场景不同的目的下会有不同的答案。

这里，谈一谈人的学习过程吧，从学习的过程中，我们来分析一下看代码和看书这两个活动。

人对新事物的学习过程基本都是从“感性认识” 到 “理性认识”的。

• 如果你是个新手，那应该多读代码，多动手写代码，因为你需要的是“感性认识”，这个时候“理性认识”对你来说你体会不到。一是因为，你没有切身的感受，告诉你Why你也体会不到，另一方面，这个阶段，你要的不是做漂亮，而是做出来。所以，在新手这个阶段，你会喜欢Github这样的东西。

• 如果你是个老手，那么你有多年的“感性认识”了，你的成长需要更多的“理性认识”，因为这个阶段，一方面，你会不满足于做出来，你会想去做更牛更漂亮的东西，另一方面，你知道的越多，你的问题也越多，你迫切地需要知道Why！这个时候，你就需要大量的找牛人交流（读牛人的书，是一种特殊的人与人的交流），所以，这个阶段，你会喜欢读好的书和文章的。

然而，对于计算机行业这个技术创新超强技术繁多的行业来说，我们每个人都既是新手，也是老手。

（最后，谢谢楼主专门来微博上邀请我回答）

读代码还是读文档，来自知乎