首先，要说明的是，这里的“新”不一定是指时间上的新，在后文中，也可能是指，对于个人（或者团队）来说是“新的”，就是说，这个东西，即使出现了很久，应用广泛，但是个人（团队）没有使用过，那么也可以说是“新”的。
本文地址：http://www.cnblogs.com/xybaby/p/8655593.html
为什么要学习新技术
计算机知识日新月异，经常会涌现出新的语言、框架、思想。虽然说这些东西不一定都是从0到1的创造发明，也许只是微创新，或者将某个领域的思想用到了新的领域。不管怎么样，都能开阔思维，扩展知识面。现实一点说，多了解一些知识在求职、跳槽的时候总是有好处的。
而对于一个技术团队，也需要了解、跟进新技术，最怕的就是总是使用同一套工具去解决所有问题。”如果你有一把锤子，那么所有东西看起来都像钉子“”。经常发生的情况时，虽然手上的这套工具、框架很烂，而且很难满足新的需求，不好扩展，但是多数人还是选择将就、缝缝补补。“丑是丑，但是还能用“，这句话透漏出妥协、逃避，也有可能是无奈。在《暗时间》里面，作者也提到了这个问题，“人倾向于在既有框架下去解决问题，而且在这个过程中很难发现框架约束的存在”。
了解、学习新技术，不是说一定要立刻使用到新技术，而是作为知识贮备，这样当现有技术无法（优雅地）解决问题的时候，可以想到有其它的技术似乎可以解决这个问题。也就是说，工具箱里面的工具需要足够丰富，才能在不同的场景下选择合适的工具。无知会限制想象力。
项目中是否采用新技术
是否要在项目中采用某一个新技术，取决于两部分：技术本身与技术之外，注意这里的新，不仅是时间上的“新”，也包括团队对技术的熟悉程度。
对于技术本身，需要充分了解技术的优缺点，需要有强大的公司或者开源社区的技术支撑，需要技术足够活跃，需要有较长的生命周期。
那技术之外的考虑因素包括哪些呢？
第一：业务、项目是否需要这个技术
第二：项目当前的阶段、时间紧迫程度
第三：团队对技术的掌控能力、也包括学习能力
要采用新技术，一定是因为业务有需求，当前的技术无法满足，或者无法优雅地、可扩展地满足，而不是说听说新技术牛逼，你就非得用一用。新技术一定是在现在或者近期来说对项目有用的，而不是为若干年后、不可预知的业务变化做准备。
如果要快速出产品原型，那么肯定是选择最熟悉的工具，如果有足够的时间预言，那么就不妨尝试新技术。处于开发前期的项目，自然是有技术试错的机会，也有较多的时间来验证新技术的稳定性。而处于开发后甚至于线上项目，那么引入新技术就得慎重且小心，因为这个时候就是在“行驶的汽车上换轮子”，如果可以， 先在小规模（部分服务）上使用新技术，经受实践的考验之后再大范围推广。
引入新技术还有一个很重要的因素，那就是团队里面必须要有负责任的成员能够hold住新技术，新技术首先可能就有缺陷，而且，使用不当也会有诸多问题，如果团队对技术的掌握没有达到一定的深度，那么出现故障的时候就会很尴尬了。下面会提到，如果要使用一个新的技术、工具、框架，我觉得需要学习到什么程度。
在团队中，一般来说，有技术追求的成员倾向于使用新技术，激进，往往只能看到新技术闪光的点；而技术leader则谨慎得多，甚至是保守，会考虑自己对技术的掌握能力，还有项目的稳定性。这个不难理解，屁股决定脑袋。
如何学习新技术
学习的目的决定了如何学习新技术，以及学习到什么层次。
只是简单了解（what is it）、还是作为知识贮备（以备不时之需）、还是现在就需要在项目中使用，学习的重点、深度、层次完全不一样。
在《学习和使用技术的4种层次》一文中，对技术的掌握分出了四个层次，大致是这个样子的：
0. Stranger（陌生人）
听说过没用过，知道一些术语和大致框架，写过hello world，没有实战经验1. Tourist（旅行者）
使用该技术开发出可用的东西，了解基本元素或者API, 了解部分技术细节，能看懂比人的代码
Salesman：学习技术的目标是为了完成某一项业务，就像旅行商去某地出差是为了卖商品而非观光一样。
Sightseer：学习技术的目标是为了拓展视野，增加见识，而非完成某项特定业务。 具有主动学习精神的开发者在业余时会时常扮演Sightseer角色2. Resident（居住者）
了解这项技术的优缺点，并深知原理，对部分细节进行深入研究，能高效使用并开发出有价值的产品或工具
Worker：团队合作为主，按时交付，保证高效
Craftsman：单兵作战，以开源自己的项目为目标3. Architect（架构者）
从更高的角度思考这门技术，举一反三，对比其他领域、技术，改革或者改善这门技术
Revolutionist：用更好的技术代替这门技术
Reformist：改善这个技术，为其发展贡献自己的力量
对于很多技术，我们可能都处于stranger这个层次，只是听说过，但既没有实践也没有了解其原理。而对于Tourist Redident这两个层次，根据学习的目标又有不同的区分，如果只是为了扩宽知识面，那么我只用关心自己关系的部分，更多的是学习这个技术优秀的地方；而为了在项目中使用，我得关心这个技术的方法面面，还需要了解这个技术可能存在的缺陷。
在《技术的正宗与野路子》一文中，作者指出了循序渐进学习新技术的方法，如图所示：
自然，不同的学习目的，需要学习到的层次是不一样的，如果是Salesman（上面四个层次中的Tourist），那么看完tutorial，就可以对照API文档写代码了；而如果想做sightseer，那就就是看完tutorial之后看关心的spec。
要在线上项目使用一个技术，至少要达到Worker这个高度，明确技术的优缺点，深知原理，高效利用，这个时候就需要对Spec和部分API进行深入学习。
最后，如果在项目中长期使用，就会发现技术的缺陷与不足，或者说与项目的实际需求不匹配的情况，这个时候要么改造它，要么重新换轮子（或者造轮子）
以redis为例
以redis为例，如果我只是希望简单了解，作为知识储备，那么我会跟着Tutorial简单使用一下，然后读一遍介绍文档，了解redis的各种特性，能做到哪些事情。
而redis本身也是一个分布式缓存，那么如果我的重点在于“分布式”，那么我会关心redis是如何水平扩展的，如何保证高可用的。这个时候，可能就是要看看相关的Specification。
那如果要在项目中使用呢，取决于使用方式与使用程度。如果只是做缓存，数据不持久化，那么就不用关心存储问题。如果数据规模不大，也不用考虑可用性，那么使用standalone这种单点redis就行了，也就不用掌握sentinel + master slave，redis cluster 或者codis，这样代码写起来简单，运维的复杂度也低了很多。
如果项目在缺乏经验的情况下开始使用redis，那么可行的演进路线是，先使用最简单的、最容易掌握的模式（如单点Redis），随着对Redis了解的深入，在小范围内使用更复杂的技术（如redis cluster），验证之后再大规模推广。