编程能力 = 领域知识 + 解题能力 + 工程能力 代码是最次要最可替代的一环。

我需要阅读源码吗？

阅读源码的前提是:

首先你要是使用者，你对这个有需求，你才会去用，在用的途中，你会发现一些地方很糟糕，有想修改的冲动，明确的有这个需求，你才会去看源码，才会去改源码，然后在途中(改源码，debug)你就慢慢理解了作者的设计实现思路，真正意义上学到东西了。

而不是为了读源码而读源码，你要对这个东西是真的感兴趣，你才能坚持下去，而最重要的一点却是人们往往不能坚持下去。

很多人往往骗自己读源码，没有需求硬整，这样子做法往往什么都没学到，并且常常中途放弃。

搞过项目的人都知道，维护老项目比自己搞新项目难度要高得多，做出来的成果还不被认可。原因是你花费了巨量时间去揣摩别人（甚至比你菜），而不是去关注业务，这很不值得。

工程项目业务是关键，架构设计的核心就是预判后续变更，让高频变更易开发（DRY），中频变更可扩展（里氏替换），低频变更影响可控（模块化/依赖接口）。

这些的关键是业务思考，你应该和人聊天而非闷头看代码。

学习需要简洁，而工程往往复杂。学牛顿力学我们讲的是理想模型，没有人用发动机拆开来讲 F=ma。

工程代码杂糅了业务、性能甚至是政治博弈，老手都犯怵你新手不直接白给。

学语法学技巧就去看书上最简明的示例，想提高工程能力就去实践中踩坑历练。

「调查问题就是解决问题」，你去踩了坑，自己就会找工具，工具能解决你的问题就是好工具，你就能建立自己的评价体系。

对于新人，最重要的是找一个自己感兴趣的事情做下去，你要把目标拆分，找出一个最小的产品，让自己先用起来或者有正向反馈，这样才能有动力接着去做。

千里之行始于足下，是低头一步一步把路走出来的。这个过程你会遇到语法问题，API 问题，莫名其妙的 bug，你发现代码设计出问题了需要重构，你一点点的把这些问题解决了，不知不觉你就做起了一个项目。

做一件事最好的时间就是当下，立即出发比啥都强。

看源码的正确方式是？

看源码也是有讲究的，读源码应该抱着查词典的心态去看.而不是脑袋空空抱着“只要我读了源码我的代码能力就会提高”的心态一头扎入代码的无穷海洋之中翻了船。

源码代表了曾经的一种局部最优的解决方案，是为了解决那时候的某一个问题，但现在的你并不理解当时到底发生了什么，敲下这几行代码的人遇到了什么样的困难，顶级程序员在代码上的表意性也不可能告诉你当时的真正情况。

所以在面对源码的汪洋大海你需要确立好方向标，我看源码到底是为了什么？是为了解决和他一样的问题，还是学习一种高性能的优化方式，我的代码性能为何如此之低，人家的为什么就这样好？带着问题和自己的解决方案再去探寻源码，即使你的方案真的很差也不要直接去翻看“源码中的答案”，因为这件事上你连一个最差的解都想不出来说明你对这个特定领域了解甚少，就像做题一样，这题你做一半卡住了差临门一脚，你看了答案觉得收获颇丰学到了新知识.但这道题上来一点思路也没有甚至不知道题目说的啥，这时候你就应该回去重新学这个章节而不是看答案把答案抄上，一是你根本不理解代码为何这么写，二是很可能所谓的标准答案只是一种极其特化的写法，把你的基本盘直接整歪了。

如果真的希望从源码了解项目，那么也请选择一个早些时期的版本去研读，一个成熟的项目早期并没有那么完善。也没有做这么多防御性编程，相对而言更能暴露出是如何解决问题的，学起来更加轻松。