程序員與新技術之間的「愛」與「恨」

咱們大部分作技術的，對新技術是又愛又恨。

愛的是他能讓枯燥反覆的工做從新得到新鮮感。

恨的是新技術太多了，學不動啊。

真到了實際要運用的時候，不一樣人對待新技術的態度相差很大，有的看上去很積極，有的又看上去很排斥。

通常來講，技術團隊的管理者每每是「排斥者」，而團隊的成員是「擁抱者」的機率居多。

看看下面這個景象是否是很熟悉？

程序員小明：老大，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. 1.Stranger（陌生人）：據說過沒實踐過，只是知道一點術語、人名等。

2. 2.Tourist（旅行者）：實現過一個完整功能。

3. 3.Resident（居住者）：瞭解這項技術能作什麼，不能作什麼。

4. 4.Architect（架構者）：有改進這項技術的能力。

Z哥我我的認爲，負責運用這個新技術的人至少要達到「旅行者」水平，纔是一個比較穩妥的狀況。

若是你的團隊中有一個「居住者」能夠隨時去諮詢，那就更棒了。

 

關於「人」，還有一點多是不少沒作過leader的小夥伴不太會有感受的，就是人員流動性致使的「單點風險」。

若是一項新技術引入後，將它引入的人員沒過多久撂攤子走了。按照勞動法，這我的能夠只停留最多1個月。若是再遇到那種職業操守差一些的就更麻煩了……

想象一下假如你是leader，這事發生在你頭上，是否是很頭疼？雖然額外多花點精力也能搞定，但這中間的風險和成本實際上是整個組織在承擔。

 

最後，第三個維度——「技術」。

Z哥認爲對「技術」的關注點主要看三個方面。

第一，關注技術的優缺點，取其長避其短。能夠問本身如下幾個問題：

1. 1.基於當前的技術棧是否有解決方案？與之相比，新技術的優點在哪，是否顯著？

2. 2.是否將全部潛在的解決方案和新技術都歸入考慮範圍了？

3. 3.全部的解決方案中，當前這項新技術的優點體如今哪兒？

4. 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

做者：跨界架構師連接：http://www.imooc.com/article/289951來源：慕課網本文原創發佈於慕課網 ，轉載請註明出處，謝謝合做