浏览器里给出来的这个属性列表是不会骗人的，用这个东西作为线索，我就很有信心。

同样可能比较适合做的资料，还有一些标准文档的附录，和源代码里的结构定义。

第二步，是建立联系。

比如说，看下面几个DOM属性：

这里，左边一列是操作Node的，右边一列是操作Element的，它就存在一定的对应关系。

一般来说，我们找对应关系的方式有以下几个依据：

美感

完备性

操作同一组数据

特别提一下，操作同一组数据，正是面向对象的核心概念，对前端而言，有点不一样的是，所有的API，根都是window，所以，其实大部分的API，可以依据面向对象的数据和操作的观点进行划分。

第三步，是分类。

这里我给出一个实际一些的例子，下图是我对zepto(移动简化版jQuery)，的API分类

建立联系以后，我们依据知识之间的联系，进行分类，就可以得到一张图谱，在这个图里面，你就可以非常清楚地知道，哪些知识，是非常重要的，哪些，其实是可以互相替代的。

而一旦有你之前没见过的东西，你又能通过把它放到图谱里，来快速理解它，或者找出一些很好的替代方案。

比如说面试的时候，如果面试官问你bind和unbind怎么用，你还不会，这时候，如果你心里有这张图，你就不至于一脸懵了，你可以说，虽然我不知道bind和unbind，但是我知道live和die啊，我又知道on和off啊。

这张图里我们就可以看出，collection里面的东西，多半没什么用，而节点操作里，肯定就都很有用。

第四步，是追本溯源。

当我对一个知识体系的全貌有了概念以后，占了全面两个字，接下来需要确认它的准确性。很多知识，在社区，会有很多的争议，该相信谁呢，这是个问题。而我的答案，就是追本溯源，去找它最初的讨论和定义。

有一个真实的案例，就是闭包这个概念，曾经我们很多人的理解都是错的，把闭包和scope的概念给混淆起来，认为闭包是函数的执行环境上下文，但是有一个叫做hax的（很多人应该都认识他，哈哈），他就对此提出了质疑，认为闭包就是函数。于是我就去查证闭包的概念。

大家都知道，wiki其实是不准确的，但是其中有一段，基本不会太有问题，就是历史。下图是closure这个词条的历史部分：

从这段历史里，我找到了一个名字，Peter J Landin，他是提出者，那么，我就去看看他到底是怎么说的，于是我去google学术搜索，找他的文章

果然找到了，于是我们看看原始的文件

这个定义，对应到我们今天JS里的闭包，是稍微有点区别的，但是它毫无疑问，是包含了两个部分环境部分和控制（代码）部分，所以其实，闭包就是对应着JS的函数，而之前，普遍的观点是认为闭包只包含环境。

所以这个追溯的过程，能够帮我们真正搞清楚对错。

除了wiki-google学术搜索的组合，还有一些邮件列表和github提交历史，也是非常适合去查证一些概念和技术的历史的。

最后说，我讲的这个建立知识体系的过程，是不断接受新知识，挑战、质疑原有的体系，推翻再重建，每一次循环，你的知识体系都变得更加坚固，更加强大。

下面分享的一部分，是关于能力培养。

能力培养其实重要性很高，但是其实说起来，内容却很少。只有两点:教材、训练。

对知识学习，我是主张建立自己的体系，不要去相信书，但是对能力培养，我的观点就刚好相反，我觉得能力的体系，恰恰是难以自己建立的，需要教材去指导。这是由两者的复杂程度和变化速度决定的。

想培养能力，就要找经典的教材来学习，像算法导论，The C++ Programming Language这些经典，几十年都没有过时。

注意这里我用了教材，而不是书。

教材和书最大的区别，就是有没有习题。

在我看来，内容再难的书可以一星期读两本，但是教材一定不行，教材一定得花几个月的时间，一边读一边做习题。

于是谈到训练。

其实有个事实是，工作以后，只有极少数人仍然能够做到训练，比如我自己的编程能力，我自觉工作7、8年，几乎没有过进步。

训练应该是系统的（需要教材）、主动的，这两个特点不可或缺，有人会觉得，我真