最近对于编程的思考尤其多，是不是到了一个新level。。。可以打高级怪了:)

最近看了一本书,叫做Google工作整理术。书中主要以作者的个人经验为核心，介绍了一套适合现代社会的信息整理方法。书中有一个例子很有意思。有一项科学试验，试验目标是一帮程序员，试验要求让各位程序员做自己不擅长的开发工作。这项研究发现，大多数程序员会根据已有经验来完成这项本不熟悉的任务。程序员们这时思想都很乱，他们会以试错的方式，将自己已有的经验套用在这项新任务中，以此达到完成的目的。然而现实是，多数时候，以往经验对于新技术的学习可能很有限。

如果对于一项新技术你能很好的把握，快速上手，那你之前一定填过很多坑。开发就是这样的，不断积累和探索，关键还是方法。

我在回顾以前，我是怎么使用新东西的时候，我发现我当时的所作所为，也是按照以往的经验进行不断的试错，这种方式十分低效，原因在于违背了大脑的运行机制。说白了就是，这东西你不会，你怎么试都是错。所以我就会在网上去搜索相关条目，按照别人的做法一步一步的做，大部分情况时不能一次到位的，其实也是一个不断试错的过程。但这种方法稍微正确一点，在于至少别人这么用过。总之，这种方式类似于复制代码，你的目的仅仅是让它跑起来。但是一问起内部运行机制就蒙圈了。

所以我现如今的方式是，学习新技术的架构，了解它的出发点，怎么设计实现，为什么这么实现，如果让我实现，我会怎么实现？而了解出发点最好地方，我觉得不是直接读源码，而是通篇阅读官方文档。

为什么不直接读源码？

国内的博客作者很多都会写一些xxx源码分析,而国外程序员很少写这种东西。更多的是写那种"xxx under the hood"，或者是"How does xxx work internally?"。给我的感觉是，从宏观上把握一项技术比单独的看一段代码更有意义。程序员的学习准则应该是0或1，也就是会与不会，没有大概、差不多、可能。。。所以使用一项技术就应该尽量的学习这项技术，只是知道怎么配置，怎么让它跑起来是不够的，还要知道这东西为啥这么设计，它通过什么方式实现了这样的操作。如果每次学习新技术都把人家的代码看一遍的话，我觉得像spring这种东西简直就是无穷无尽的。所以相比较阅读源码，我认为阅读官方文档更重要。在知道这东西做了什么事之后，再去看代码会清晰很多，因为你是知道这样做的目的是什么的。比如像spring下面的各个子项目，文档不要太多好吗。很多人认为通读文档太浪费时间，等到读完文档了，交付日期早都过了。但是文档中介绍内部工作机制的，绝对不能错过，这是学习的绝佳机会，也许你可能一辈子都不会自己写一套权限验证系统，但是学习spring security的内部工作机制一样会对你的工作产生积极的影响。久而久之，当你看过足够多的技术实现后，你就会触类旁通。当有一天，真要你实现一个复杂的系统的时候，那些你看过的技术实现一个个都会浮现在眼前。