如何阅读书籍 & 学习、使用技术的四种层次

如何阅读书籍

摘要

这篇文章从如何阅读书籍出发，简单讨论了如何选择书籍、是否阅读原版和阅读数量这几个常见问题，然后自己的阅读问题进行了分析和总结。

注意

1. “如何阅读”指“What to read”而非“How to read”，Mortimer J. Adler的怎样阅读一本书对How to read有着精彩的描述。
2. “书籍”指非小说（Non-fiction）类书籍。

目标

我是一个功利主义者（Utilitarianism），因此我认为阅读的目标在于为自己创造实际价值，所以：

1. 我不会因为某本书看起来很有趣就去阅读（机会成本）。
2. 也不会因为很多人推荐某本书就去阅读（从众）。
3. 更不会因为某本书难就去阅读（追求智商优越感）

一本书值得阅读，当且仅当：

1. 它可以直接为我创造价值。
2. 它可以间接为我创造价值。

我的阅读目标：

形成T型知识结构：专业知识尽可能深入，专业周边知识尽可能精炼。

如何选择？

专业书籍

专业知识尽可能深入。

我是一个软件开发者（Software Developer），因此这里的专业书籍均和软件开发有关。

这里介绍我自己用的两种方法：

根据引用列表

从一本经典书籍出发，深度优先遍历它的引用列表，通过书评和摘要了解这些引用书籍，再根据自己的实际情况决定自己的阅读次序。

这里以代码大全为例（为了方便和一致性，这里使用英文书名）：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Code Complete：软件构建全程最佳实践指南。 | |----How to Solve it：系统解决问题。 | |----Conceptual Blockbusting：跳出思维的壁垒。 | |----Mythical Man Month：软件工程不能做什么。 | |----Programming Pearls：极简算法手册。 | |----The Science of Programming：编写正确的程序。 | |----Writing Efficient Programs：编写高效的程序。 | |----Pragmatic Programmer：高效程序员的实践。 | |----Refactoring：如何改进自己的代码。 | |----Programming on Purposes：用正确的编程模式处理问题。 | |----Software Tools：用合适的抽象封装复杂度。 | |----The Practice of Programming：极简编程风格指南。 | |---- Writing Solid Code：减少调试的时间。 | |---- Elements of Programming Style：极简编程风格指南。

可以发现，通过代码大全一本书，经过短短两层引用联系，几乎可以找到2004年以前所有软件开发的经典书籍。事实上，我阅读的80%以上的软件开发经典书籍，都源自于代码大全的引用列表。

这种方法的好处：

• 简单直接：相对于从茫茫书海里找出10本经典书籍，找1本经典书籍再从它的引用列表里面找到20本经典书籍要容易的多；
• 质量保证：靠谱书籍的引用书籍的质量一般都很高；
• 发现一些被忽视的经典：相当一部分的书籍随着时间的流逝而淡出人们的视野，但这并不代表它们本身没有价值，例如：
  • Programming on Purposes
  • Software Tools
  • The Science of Programming
  • Writing Solid Code
  • Writing Efficient Programs
  • 等等… 这些书或者绝版，但它们都对我的软件开发理念产生了巨大影响。
• 形成知识体系：引用书籍彼此具有天然的联系，这使得创建知识体系更加容易。

我认为这种方法适用于任何需要严肃阅读的领域：

1. 锚点：找到一本经典书籍。
2. 撒网：了解该书引用列表中的书籍。
3. 收网：根据自己实际需要，精读相关书籍。

根据作者

这里以计算机书籍为例（以下仅代表个人口味）：

1. Richard Stevens：善。
2. Brian Kernighan：极善。
3. Deitel Series：翔。
4. Bruce Eckel：废话连篇。
5. Jon Bentley：善。
6. Andrew S Tanenbaum：大善。
7. Jeffrey D Ullman：善。
8. P.J. Plauger：大善。
9. Robert C Martin：善。
10. Bjarne Stroustrup：善，但略神叨（神侃世界观方法论有点顶不住）。
11. Martin Fowler：善，但略唠叨。
12. Ron Jeffries：翔（好吧我是故意来黑的，尼玛连个Sudoku都解不出来写毛程序）

这种方法的问题在于需要一定阅读经验，但是它非常有效——以至于不用看内容就对书的质量有七八成把握。

非本专业书籍

专业周边知识尽可能精炼。

1. 对于专业周边知识，了解关键概念及指导思想即可。
2. 不需要，也没有必要对专业周边知识进行深入了解。
3. “Know what” is enough, “Know how” is expensive.

以我2年前编写手机应用，学习用户体验为例：

1. 分别在现实中（身边有几个很不错的交互设计师）和线上（Quora和知乎）进行提问和搜索，得到一个书单。
2. 按照下面的原则过滤书单：
   • 去掉教科书和大部头。
   • 去掉包含大量原理或论证的书籍。
   • 保留结论型书籍。
   • 保留指南型书籍。
3. 总结出书单，迅速的阅读并找到关键点。
   • 给大家看的设计书：CRAP原则，字体与配色。
   • 设计心理学：心智模型，心智摩擦，最小惊讶。
   • 交互设计之路：为什么需要交互，交互有哪些坑。
   • Tapworthy：具有实际操作性的移动平台交互设计指南。

了解设计的人可能认为上面的书单过于初级——没错，它们都是结论型或指南型书籍，没有原理，也没有论证——但这正是对于我这样的非专业者所需要的书籍：我不需要知道这些知识是怎么来的，知道怎么用足矣。

此外，受价值驱动，而非兴趣——大多数情况下兴趣只是把自己脱离当前困境的接口。

学习型书籍

学习型书籍是一种元（Meta）方法书籍：这类书籍用于提升学习能力，换句话说，就是缩短吸收知识所需要的时间。

这类书籍我只读过下面的几本，效果有但不明显：

• 学习之道：冥想，体会。
• 如何阅读一本书：检视阅读，主题阅读。
• Learn more, study less：建立知识体系及联系。

需要注意的是，不要陷入到寻求最优学习方法的误区——Best is the worthest enemy of better。

阅读原版？

如何在翻译版和原版做选择？

1. 优先选择翻译版。计算机书籍这种描述精确知识的书籍更是如此。
2. 此外，如果阅读中出现难以理解的问题，不要下意识的把其归咎于翻译问题——多数情况是理解问题。

为什么还有那么多人阅读原版？

1. 因为翻译版还没出版。
2. 知识的价值有其时效性。
3. 逼格。

越多越好？

我经常逛豆瓣，豆瓣有一个很有意思的现象就是人们喜欢去比较自己每年读书的数量，或者是截图炫耀自己读过几千本书云云。

我在这里酸一下：书的数量并没有什么参考价值，就好比无法用盖一栋大楼的砖数评价这栋大楼的质量；换个说法，Effort不等于Progress。

关键在于读过书的质量，吸收的程度，以及创造的价值。

此外，盲目追求读书的数量会带来另一个问题——浅尝辄止。本应花在专业书籍上的时间被分配到其它无关紧要的事情上，导致该学好的没学好，没必要的学了一滩但用不上。

总结

1. 形成T型知识结构：专业知识尽可能深入，专业周边知识尽可能精炼。
   • 按照引用列表和作者深入阅读专业书籍。
   • 利用结论型/指南型书籍精炼阅读专业周边书籍。
   • 不断强化自己的按需学习能力。
2. 不一定非要阅读原版。
3. 读书并非多多益善。
4. 读书之前回答下面几个问题：
   • 这本书能给自己带来什么改变？
   • 自己是否需要这种改变？
   • 如果均为Yes，继续；如果有一个No，砍掉。

学习&使用技术的四种层次

关于

Bjarne Stroustrup在他的新书《A tour of C++》

里面举了一个旅行的例子来比喻初学编程语言：

…as an analogy, think of a short sightseeing tour of a city, such as Copenhagen or New York. In just a few hours, you are given a quick peek at the major attractions, told a few background stories, and usually given some suggestions what to see next…

…you do not know the city after such a tour. You do not understand all you have seen and heard. You do not know how to navigate the formal and informal rules that govern life in the city…

…to really know a city, you have to live in it, often for years.

简而言之，编程语言是City，而开发者则是Traveller——这是一个很有意思的比喻，在这篇文章里，我试图延续这个类比（Analogy）——把这个类比放大到初学，掌握，了解以至精通一门技术的层面。

不过需要注意：我自己并没有精通哪一门技术——所以这篇文章的内容是值得怀疑（susceptible）的，但它可以作为一个不错的参考。

0. Stranger（陌生人）

使用一项技术最初的层次就是听说过没用过——就像我们之中的大多数人都听过南极，听过北极，知道南极有企鹅，北极有北极熊，但是却从来没有去过南极或北极。

Stranger具有以下的特征：

• 知道这项技术的名字。
• 知道这项技术的一些术语。
• 知道这项技术的一些关键人物的名字。
• 了解少量技术的细节，但没有使用这项技术的实际经验。

以我本人和RoR来打个比方：

• 知道RoR是Ruby on Rails。
• 知道Rails，Gem和Rake的存在。
• 知道DHH也知道松本行弘。
• 看过The Ruby Programming Language，还使用一个基于RoR的博客框架Octopress写博客。
• 但从来没有使用RoR去搭建网站。

所以我是一个RoR的Stranger。

对于新技术，绝大多数人都是Stranger——但是就我对国内技术社区的观察，相当数量的Stranger意识不到自己还是Stranger——认为知道一点术语一些人名就算了解一门技术，甚至把它写在简历上（Familiar with XXX）或是开始与别人进行讨论（当然都是毫无意义的讨论）。

1. Tourist（旅行者）

当开发者真正开始用一项技术作出了可以用的东西：

• 面向用户的产品（End-User-Oriented Product），比如一个手机应用，或是一个浏览器插件。
• 或是面向程序员的工具（Programmer-Oriented Tools），比如一个页面抓取框架，或一个简单的Parser Generator。
• 注意教科书范例（Textbook examples）和Hello world不属于可以用的东西——这些只是Dead Code——被执行一两次，然后被遗忘。

这时这个开发者就进入到了Tourist阶段：

• 了解这项技术的基本元素。
• 使用这项技术做出了实用的产品或工具。
• 了解对这项技术的部分细节。

根据的学习目的的不同，Tourist又可以分为Salesman和Sightseer。

1.1. Salesman（旅行商）

Salesman是具有明确目的的Tourist——他们学习技术的目标是为了完成某一项业务，就像旅行商去某地出差是为了卖商品而非观光一样。

绝大多数职业开发者在开发生涯中都会扮演Salesman这个角色——接到一个任务，涉及到某项不熟悉的技术，需要在限定时间内完成。

1.2. Sightseer（观光者）

和Salesman相反，Sightseer学习技术的目标是为了拓展视野，增加见识，而非完成某项特定业务。

具有主动学习精神的开发者在业余时会时常扮演Sightseer角色——找到自己认为有价值的新技术或是基础知识进行系统学习，从而拓宽视野，提高水平。

2. Resident（居住者）

如果一个旅行者在一个地方待了半年以上，那么他/她就会变得原来越像当地人。随着Tourist对某项技术的日益精进，他/她会逐渐演变成这项技术的Resident：

• 熟悉这项技术的基本元素。
• 熟悉这项技术的生态系统（Ecology）：既包括开发工具（编辑器，命令行工具，集成开发环境等），也包括开发社区（讨论组，邮件列表等）。
• 了解这项技术能做什么，不能做什么。
• 了解这项技术有那些坑，如何绕过这些坑，以及识别这些坑带来的问题。
• 对某些领域有深入的研究——但并不受限于特定领域。
• 使用这项技术做出了有相当价值的产品或工具。

同Tourist一样，根据使用技术的目标不同，Resident可以分为Worker和Craftsman：

2.1. Worker（工人）

技术是Worker的谋生手段，一个优秀的Worker应具备以下特征：

• 对于给定问题，知道如何给出经济有效的解决方案。
• 以团队合作为主，了解团队合作的价值，能够推动团队项目健康前进。
• 追求按时交付。

2.2. Craftsman（工匠）

同Worker不同，技术并非Craftsman的谋生手段，而是某种“副业”——用来提升声望，修炼开发水平。

一个优秀的Craftman往往具备以下特点：

• 对于给定问题，知道如何给出优雅的解决方案。
• 以单兵作战为主，主要靠个人推进项目，但也能进行一定程度的团队合作。
• 追求极致美感。

3. Architect（架构者）

有想法且有能力的人在一个地方待久了都会有将这个地方变的更好的冲动——一种方式是从源头出发，推翻旧制度建立新社会，也就是革命；另一种方式则是保留现有的制度，对其进行温和但持续的改进，也就是改良。

技术也是如此，任何技术都跟不上开发者成长的脚步，当这种差距到达一定程度时，就会有卓越的开发者站出来，创造出新的技术，他们就是Architect：

• 熟悉多项互相关联的技术，并了解他们的优势和不足。
• 具备强大的领导能力，深厚的基础和大量实际开发经验。
• 能够带动整个技术的生态系统发展。
• 好吧，我编不下去了（尼玛我要都知道我还至于是IT苦屌么 –_-）

如果你看过Matrix 2: Reloaded

就会知道Architect这个词放在这里再好不过。

根据目标不同，Architect分为Reformist和Revolutionist。

3.1. Reformist（改良者）

改良者的目标：把现有技术变的更好。（Makes existing technology better）

例如：

• GoF总结Design Pattern。
• John Resig创造jQuery。
• Anders Hejlsberg为C#引入LINQ。

3.2. Revolutionist（革命者）

革命者的目标：用更好的技术取代现有技术。（Replaces existing technology with better one）

例如：

• Alan Kay把细胞的概念引入软件开发]进而创造出OOP的核心概念。
• Don Knuth对计算机算法（TAOCP）以及计算机排版（TEX）的贡献。
• iPhone于2010年之前的任何手机（iPhone4除外）。

小结

这篇文章利用A Tour of C++里的隐喻，把学习/使用技术分成了四个层次七个头衔：Stranger，Tourist（Salesman，Sightseer），Resident（Worker，Craftsman），Architect（Reformist，Revolutionist），然后给出了各个头衔所应具备的特征和能力。

关于同类文章

之前也有类似的文章，例如程序员的十层境界和开发者的八种境界

这些文章的共同点：

1. 看似很牛逼但回想一下啥都没说。
2. 不会给人带来什么价值。
3. 没有一个鉴别的标准。
4. 没有指导性，也没有使用价值。

本文的应用场景

考察状态

以我自己对编程语言的掌握为例：

• C/C++: Stranger.
• Python: Craftsman.
• Java: Worker.
• C#: Craftsman.
• JavaScript: Sightseer.
• Scheme: Sightseer

将上面的列表转置：

• Stranger: C/C++
• Sightseer: JavaScript, Scheme
• Worker: Java
• Craftsman: C#, Python

结合这些头衔的定义，一目了然。

制定计划

运用本文的词汇，可以进行非常精炼的计划制定：

• 例如 Make a thoroughly sightseeing of C++；
• 或是 Become a proficient worker on IntelliJ；
• 抑或 Take a short tour of Sublime Text。

部分内容原文链接：http://lucida.me/blog/levels-on-learning-and-using-technologies/