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

　　首先，要說明的是，這裏的「新」不必定是指時間上的新，在後文中，也多是指，對於我的（或者團隊）來講是「新的」，就是說，這個東西，即便出現了好久，應用普遍，可是我的（團隊）沒有使用過，那麼也能夠說是「新」的。

　　本文地址：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種層次

技術的正宗與野路子