首先，要說明的是，這裏的“新”不一定是指時間上的新，在後文中，也可能是指，對於個人（或者團隊）來說是“新的”，就是說，這個東西，即使出現了很久，應用廣泛，但是個人（團隊）沒有使用過，那麽也可以說是“新”的。

　　本文地址：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），驗證之後再大規模推廣。

references

學習和使用技術的4種層次

技術的正宗與野路子

如何學習新技術、團隊技術選型時要註意些什麽