如果第二次看到我的文章，歡迎「文末」掃碼訂閱我個人的公衆號（跨界架構師）喲~
每週五早8點 按時送達到公衆號。當然了，也會時不時加個餐～
我的第「80」篇原創敬上
5900字鉅獻奉上
我們大部分做技術的，對新技術是又愛又恨。
愛的是他能讓枯燥反覆的工作重新獲得新鮮感。
恨的是新技術太多了，學不動啊。
真到了實際要運用的時候，不同人對待新技術的態度相差很大，有的看上去很積極，有的又看上去很排斥。
一般來說，技術團隊的管理者往往是“排斥者”，而團隊的成員是“擁抱者”的概率居多。
看看下面這個景象是不是很熟悉？
程序員×××：老大，XX系統太亂了，需要重構一下。我建議用XX技術，它的優點有XX、XX、XX。我開了一個分支，在項目中引入測試過了，沒啥問題。重構應該要趁早，否則簡直是煎熬啊，而且越拖改造成本越大。SDK都找好第三方的了，成熟的。有一千多個star，作者說它的性能比現在我們在用的要好上X倍。
Leader小王：爲什麼需要引入？ 你現在遇到了什麼問題需要它來解決？
程序員×××：這不是正好打算重構嘛
Leader小王：他的缺點是什麼？
程序員×××：……
Leader小王：引入的過程是怎麼計劃的？分幾個階段？預計的時間節點？
程序員×××：……
此時，×××的心裏肯定有一萬隻草泥馬奔過。這不就是典型的保守派反對革新派的最好體現麼。
其實Z哥覺得，引入新技術是好事，也是一個組織尋求專業性進步的必經之路。
但是，你回想一下你工作中用到過的新技術，哪怕是引用一個很小的類庫，有沒有被“坑”過？我估計每個人都被“坑”過吧：D
這些“坑”其實是由於我們自己之前做出的錯誤選擇所導致的。而導致作出錯誤選擇的原因是因爲，在對待新技術上，我們僅僅通過片面的信息做判斷是不夠的。
當你看到各大技術社區的官方公衆號都在說某個新技術好的時候，有沒有觀察過，他們一年有說過幾次什麼新技術不好？
當你聽說某個新技術以N倍性能碾壓其它框架的時候，是不是有考慮過，信息提出者的測試方式是否嚴謹、客觀？
哪怕在技術圈被廣爲認可的github star數，在某寶上都已經出現了提供刷star送fork的服務了……
不過這還不是最可怕的，最可怕的還屬粉絲文化。因爲XX在用，所以這玩意好；因爲這是XX出的，所以這玩意好。
圍城裏的人總覺得外面的世界精彩，做技術的我們也是。隨着時間的推移，老技術對我們來說越來越無趣，總覺得外面的新技術如此的美好。
Z哥仔細想了一下背後的原因，猜測可能是以下三點。
第一，放出消息的源頭往往是新技術的創造者。
那自己肯定不會拆自己的臺，所以你在網絡上看到的新技術的信息，大多都是正面的。
第二，哪怕我們抱着求實的心態來選擇，也會不自覺的將驗證外界宣傳的優勢是否屬實，作爲優先考慮的下手點。
這其實就被引導到新技術擅長的方面去了，進一步擴散了新技術優點的傳播。
相對的，缺點和缺陷是充滿未知性的，創作者自己知道的信息也不一定全，要不然也不會產生bug了。
第三，經過大量正面輿論的薰陶，會讓你對它“心生期待”。此時，你心裏的天平就已經傾斜了，促使你只會看到自己希望看到的“有利”信息。
這正如，醫生被打了，患者就大肆說打得好，而其它的醫生就無比委屈的說這行沒法幹了。道理是一樣的。
所以總的來說，相比一個新技術的優點，其實，它的缺點、或者說邊界是什麼，更有價值。
但缺點只有實際踩到坑了纔會知道，這個需要投入時間去實踐。再加上“揭別人短”相當於給自己樹敵，代價是很大的，所以那些遇到“坑”的人願不願意分享出來還不好說。
其實，並不是所有的慎重都等於保守。
新技術、新理念的出現，自然有它的誘惑，技術總是在不斷前進，擁抱變化本身沒有問題。但是引入不成熟的技術看似能帶來短期的收益，但是它潛在的風險以及間接成本（跨組織的影響、長期的維護成本等）可能遠遠大於收益。
所以，要“正視”新技術，我們還是要回到價值本身來看。
在產品經理屆有一個很知名的公式，是百度貼吧之父俞軍提出的：用戶價值=(新體驗-舊體驗)-替換成本。
其實在技術領域也適用，我們來改造一下：技術價值=(新效益-舊效益)-替換成本。
帶着這樣的一個公式去思考，我們才能清楚的認識到這個新技術對你的意義到底是什麼？
新技術理應讓我們的工作能夠開展的更好，而不是相反。
所以，我們除了要看到新技術的好處之外，還要思考好處的背面是什麼？以及想想是不是有什麼部分被我們忽略了？
Z哥認爲可以從兩個角度來考慮這個事情。
一個是考慮的維度要“廣”
一個是準備的程度要“深”。
考慮的維度要“廣”
“廣”並不是單純數量的多少，而是我們不能僅僅站在技術維度來考慮這個事情。
Z哥認爲至少需要從3個維度來考慮，從重要性從高到底分別是：業務 > 人 > 技術。
首先，關於「業務」這個維度，我們要先弄清楚當前業務上面臨的問題是什麼，什麼是最重要的。
我們必須貼着業務來選擇，因爲在不同的業務階段，會有不同的選型方式。
初創期，最重要的是“靈活”、“快速”。
成長期，最重要的是“可靠”。
維護期，最重要的是“低成本”。
關於維護期，我想多說幾句。我知道做技術的人中有不少是「完美主義」者，可能你會覺得「低成本」不就是將就嘛，得過且過。
這種感覺我懂。
但是作爲一個過來人，我想勸你一句，回到現實。
代碼永遠有變亂的趨勢，因爲功能永遠是增加多於刪除的，代碼複雜度會隨着代碼行數的增長而增長。
在維護期，你必須得正視各種遺留代碼的遷移成本，如果改變技術選型會帶來遺留代碼重寫，這背後帶來的代價業務必然無法承受，那麼我們就不得不考慮在現有技術選型之上做一些小修小補或者螺旋式上升的重構。
正因爲技術選型和業務相關，所以你會發現身邊的情況符合以下規律：
新技術往往被創業公司或大公司的新興業務使用
中大型公司的核心業務則更傾向於用穩定的技術，至少三五年以上吧。
一個公司如果長期使用一種技術，就會傾向於一直使用下去，甚至連版本都不太願意更新。
現在你應該明白了，這些現象背後都是有道理的。
如今的互聯網講究的是精細化，在運營層面講究的是用戶分層。其實我們做技術的也可以考慮精細化和分層。
除了前面提到的「初創期」、「成長期」、「維護期」三個粗粒度的時期，我們還可以在同一個時期精細化的“橫切幾刀”。
怎麼切法？
其實就是再做一下歸類。
短生命週期產品和長生命週期產品？
邊緣產品和核心產品？
Z哥認爲，只有長生命週期&邊緣產品才適合引入新技術。
因爲只有這樣，你纔有足夠的時間去“踩坑”，不會半途而廢。而且，也只有邊緣產品纔能有“命”支撐你折騰下去。
我們再聊聊第二重要的維度「人」。
康威定律深刻地影響着很多方面，技術選型也不例外。特別是做宏觀技術選型時，必須考慮它在最終技術架構中的位置，以及與團隊溝通結構的匹配程度。
即使是一項很先進的技術，假如它與體系中的其它技術棧不匹配，也可能導致翻車。
另外，團隊裏面必須要有負責任的人員能夠hold住新技術。
那麼，什麼纔算hold得住？
我覺得C++之父Bjarne Stroustrup在他的《A tour of C++》中對熟練度的分層已經有了很好的闡述。
他將程序員們掌握一項新技術的熟練度分爲了4個層次（順序由初級到高級）：
1.Stranger（陌生人）：聽說過沒實踐過，只是知道一點術語、人名等。
2.Tourist（旅行者）：實現過一個完整功能。
3.Resident（居住者）：瞭解這項技術能做什麼，不能做什麼。
4.Architect（架構者）：有改進這項技術的能力。
Z哥我個人認爲，負責運用這個新技術的人至少要達到「旅行者」水平，纔是一個比較穩妥的情況。
如果你的團隊中有一個「居住者」可以隨時去諮詢，那就更棒了。
關於「人」，還有一點可能是很多沒做過leader的小夥伴不太會有感覺的，就是人員流動性導致的「單點風險」。
如果一項新技術引入後，將它引入的人員沒過多久撂攤子走了。按照勞動法，這個人可以只停留最多1個月。如果再遇到那種職業操守差一些的就更麻煩了……
想象一下假如你是leader，這事發生在你頭上，是不是很頭疼？雖然額外多花點精力也能搞定，但這中間的風險和成本其實是整個組織在承擔。
最後，第三個維度——「技術」。
Z哥認爲對「技術」的關注點主要看三個方面。
第一，關注技術的優缺點，取其長避其短。可以問自己以下幾個問題：
1.基於當前的技術棧是否有解決方案？與之相比，新技術的優勢在哪，是否顯著？
2.是否將所有潛在的解決方案和新技術都納入考慮範圍了？
3.所有的解決方案中，當前這項新技術的優勢體現在哪兒？
4.使用新技術，會帶來哪些新問題，嚴重麼，我們能否解決掉？（如運維、培訓學習、潛在風險等）
關於第4點還有兩個延展問題：
如果這項新技術可以替代現有的一些方案，那麼我們能不能保證將來把相關的開發都遷移到這項新技術上？
如果不能保證，那麼如何確保這項新技術未來有足夠的精力去“填坑”和進一步深入？
第二，弄清楚該技術值不值得“長期信賴”。這需要我們對它的發展前景有一定的認識。
建議你可以從以下6點來考量。
1.一項優秀的技術和企業一樣，應該有其明確的定位和發展路線。清楚地表明自己要做什麼、不做什麼，以及未來一段時間的規劃。
大多數情況下，說自己的框架“包治百病”、多麼多麼完美的，往往在未來等待你的是“大坑”。
2.有沒有持續投入的人或者社區。開源技術的物質收益是微乎其微的，所以一項開源技術要想走的遠，關鍵就看背後的支持者是誰。
這對個體來說是很難的，所以大部分情況下，選用背後有知名組織支撐的技術，會更靠譜一些。比如各大互聯網巨頭、XX基金會等。
3.問題解決的速度如何。這其實是對前面這點的補充，體現的是維護這個技術的組織活躍度和積極性如何。
想象一下，當你在生產環境遇到一個棘手的問題，提了一個issue但遲遲沒人響應，是多麼揪心的一件事。
4.源碼質量。源碼質量除了通過閱讀代碼獲得的主觀評價之外，還可以通過「單元測試覆蓋率」來觀察。因爲單元測試體現的是維護者的工程化意識和能力。
5.文檔質量。如果文檔很雜亂的話，說明維護者缺少站在使用者考量的意願。可能未來會有很多華而不實的功能出現。
6.開源協議。有的協議比較寬鬆，如BSD、MIT；有的協議相對嚴格，如GPL。大部分情況下，選擇的協議越寬鬆，發展的速度和前景都會更好一些，畢竟對大家來說，自由意味着更少的顧慮，更廣的運用空間。
第三，永遠不要忘了「技術成熟度曲線」的存在。
有些新技術由於有大牛或者大公司背書，一經推出很快就成熱門了。但是，幾乎所有的新技術都得經歷下面這麼個週期。
▲圖片來源於網絡，版權歸原作者所有
所以，我們還是要注重技術推出的時間有多久，以及業界有多少實際的使用案例、口碑如何。以此來判斷現在是不是處於「穩步爬升期」和「成熟期」。
真正搞清楚了上述「業務」、「人」、「技術」這三個維度的考量，心裏就“有譜了”。
接下去再通過幾個步驟的充分準備，層層深入。
準備的程度要“深”
Z哥建議的準備過程是分爲5個步驟。
前面四步本質上就是一個篩選的過程，越往後剩下的方案會越來越少。
第一步「調研」可能很多人都做過，本質就是一個收集信息的過程。
看似最簡單的一個事情，只要手指點點。但恰恰是最大程度體現新手和高手差距的地方。
因爲，雖然大家輸入的信息一樣，但是高手往往能看到更多的複雜性，識別出更多有價值的信息。
其實，做好「調研」工作的關鍵就是要先搞清楚你想了解哪些信息，帶着目的去收集。
前面一節「考慮的維度要“廣”」中講的內容就是一些普適性的有價值信息。你可以先照着這些點去收集信息。
第二步「候選對比」。大多數情況下，解決一個問題的方案是存在多個的。所以這一步就是將你從外部收集到的信息，整理成一個方便對比的格式，比如下圖這樣。
我見過很多的準備工作做到這步就結束了，就開始決定用哪一個了。
毛主席說過，“實踐是檢驗整理的唯一標準“。所以我們需要繼續做第三步，「關鍵技術驗證」。
通過親自動手，驗證每個選項中看上去最具優勢的幾個點是否屬實，並且搞清楚它背後的原理以及同時存在的副作用。這纔是知其然的同時，知其所以然。
另外，如果對性能很重視，那麼親自去壓測一下是必不可少的。特地標紅強調一下：D
如果是一個「長生命週期&核心」產品的技術選型，可以考慮進行第四步，「場景驗證」。
找到該項目中的最重要的場景，將可預知的極端情況搭建成原型Demo，進行驗證，並在多個方案之間進行比較。
比如，將它們放到真實的海量數據場景裏，看看到底哪個對數據量的支撐做的更好。
至此，你終於得到了一個經過你質量認定的解決方案，離開始運用只剩最後一項準備工作了，「制定實施計劃」。
實施計劃會千差萬別，但是一份好的實施計劃肯定是滿足以下兩個要素的。
始終將“怎麼降低風險”放在第一位。
接地氣，循序漸進，而不是“一刀切”。
以上工作全部做完之後，我們會形成一份這樣的《引入XX類新技術方案》的文檔。
▲公衆號後臺回覆「引入新技術SOP」可獲取該模版
大功告成！
經濟學視角的解讀
如今，軟件開發行業中的開源力量越來越強，在這個充滿誘惑、充滿選擇的時代，保持理性、客觀顯得格外的重要。
最怕自己學會了這種新技術後，就會有種“拿着錘子找釘子”的感覺，將新技術濫用於各種項目。
鞋子好不好，只有腳知道。
但是當你腳感覺到不舒服的時候，已經晚了。你不得不忍着再走一段路。
新技術的引入其實也可以用經濟學來解釋。經濟學中一個很重要的觀點是：有選擇就有成本，你放棄的最大價值就是你作出這個選擇的成本。
例如，當你選擇引入新技術的時候，其實你放棄的就是過去所積累的穩定性。能否將可能要承擔的風險控制在放棄的價值之下呢？
當然了，過度的保守主義也是不提倡的。因爲經濟學中還有一個很重要的觀點：沉沒成本不是成本。
當你已經投入了很大的力氣去優化老的解決方案，但還是無法達到你的要求的時候，不要捨不得，應該果斷的選擇更換。
因爲老方案的未來價值很小了，爲了堅持拿着今天的這個“芝麻”，你放棄的可能是後天的“西瓜”。
就像docker選擇擁抱k8s，放棄了自己的“親兒子”Swarm，也是爲了避免未來丟了自己容器領域No.1的地位。
總結
好了，總結一下。
這篇呢，Z哥先幫你分析了一下，大家在引入一個新技術的時候常見的誤區，以及應該如何科學的來看待這個事情。
其次，我建議從「業務」、「人」、「技術」三個維度來擴展你思考的“廣”度，以及通過5個步驟，來讓準備工作更加的深入一些。
最後，藉助經濟學視角的解讀，讓你有了一個更理性的認識。
以上，希望對你有所幫助。
推薦閱讀：
作者：Zachary
出處：https://www.cnblogs.com/Zachary-Fan/p/newtechnology.html
如果你喜歡這篇文章，可以點一下左下角的「推薦」。
這樣可以給我一點反饋。: )
謝謝你的舉手之勞。
▶關於作者：張帆（Zachary，個人微信號：Zachary-ZF）。堅持用心打磨每一篇高質量原創。歡迎掃描下方的二維碼~。
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公衆號「跨界架構師」，回覆「技術」，送你一份我長期收集和整理的思維導圖。
如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關注我的公衆號「跨界架構師」，回覆「運營」，送你一份我長期收集和整理的思維導圖。
定期發表原創內容：架構設計丨分佈式系統丨產品丨運營丨一些深度思考。
