你們好，我是飄渺。前端
前幾天跟一個團隊技術負責人聊天，他說他們有個小的項目都是直接使用的SpringCloud。java
我問他爲何，你這不是爲了技術而設計嗎？小項目用個單體架構不是很方便嗎？程序員
他說我就是想用一下SpringCloud，熟悉一下。數據庫
我問他，那你在使用SpringCloud過程當中有沒有遇到一些問題，好比數據庫怎麼拆分？事務問題如何解決呢？怎麼作的CICD？編程
他又說咱們不拆，就一個庫。只不過在應用層規定了服務與服務之間只能經過接口調用，至於分佈式事務嘛，暫時還沒考慮。服務器
。。。。。。微信
都說興趣是最好的老師，熱衷新技術自己也是沒錯的，可是這樣很容易形成一個問題就是在作項目的時候爲了技術而架構，簡單問題複雜化。架構
那軟件工程師到底應該如何應對新技術呢？（固然這裏提到的SpringCloud並不算什麼新技術了）咱們看看 Karl Hughes 是怎麼說的！框架
原文地址：http://t.hk.uy/8yS編程語言
2015 年，我帶領一支工程團隊爲大學生構建了一個 Web 應用程序。因爲錄取工做已於 5 月結束，所以咱們只有 3 個月的時間爲每一年 8 月的流量暴漲作好準備。
第一年咱們只有幾千個用戶，因此沒有人擔憂擴展問題。咱們使用了 Angular 前端和 MySQL 數據庫，在 PHP 中構建了這款應用。
第一年結束時，咱們的應用程序架構
當咱們準備在第二年將用戶規模增長到三倍時，咱們開始懷疑現有的應用程序可否良好地擴展。我開始學習全部最新的工具，聘請了一位經驗豐富的 DevOps 工程師，而後制定了一項負載測試計劃。
通過兩個半月的混亂，研究了 Docker、Azure Service Mesh 和其餘一些最新工具後，咱們意識到沒法遇上 8 月的截止日期。咱們退後一步，從新考慮了所面對的問題。我開始向一些導師尋求建議，記得那天，其中一位叫我出去，對我說：
「你不須要那麼多複雜的工具！」他告訴我。「在系統上再扔一臺服務器就好了。」
爲何新技術如此吸引人？
像許多工程師同樣，我會抓住機會利用全部最酷的新工具。通過幾個月的無謂嘗試，我終於意識到解決方案原本很簡單，而且咱們手頭已經有了所需的工具。咱們水平擴展了 API，垂直擴展了數據庫，這花了大約兩週時間。
第二年開始時，咱們的應用程序架構
過後看來這顯然是正確的選擇，可是爲何一開始它就不那麼明顯呢？爲何甚至很有經驗的軟件工程師也會像飛蛾撲火通常被閃亮的新技術所吸引？
新技術承諾解決老問題
管理大量服務器很是困難，一直以來都是一個難題。當咱們遷移到雲後，這個問題終於變簡單了，如今 Kubernetes 承諾可讓這件事情變得更輕鬆。與全部「煩人的舊東西」相比，新技術有望更快、更高效或更靈活地解決問題。若是你只看那些宣傳資料，你可能會認爲它們甚至沒有任何代價可言。
咱們會由於用上了「最新和最棒的技術」而受到關注
我在 2015 年讀到的全部文章都在說 Docker 將會有多偉大。他們堅持認爲它將在短短几年內取代 VPS。早期採用的公司所以獲得了不少正面的報道。我也想要這種關注。
求職者涌向新技術
不幸的是，由 Hacker News 推進的炒做週期使工程師認爲他們必須採用最新技術才能跟上時代。對於新手開發人員來講尤爲如此。你想不到最近有多少培訓班畢業生問我是否在使用新出的 X 或 Y 框架。甚至有人試着勸我將咱們的整個關係數據庫轉移到區塊鏈上。
咱們也想變得很酷
「深刻其中並對全部事物作現代化改進是頗有趣的事情——固然，你能夠在此過程當中學到不少東西（也許會以犧牲業務爲代價）。」——David LeBlanc
我對豐富簡歷內容沒什麼興趣，但我記得那時候我會想：「這將成爲一次會議演講上的精彩故事。」我如今可不敢這麼說，由於在 2015 年的早期創業階段嘗試部署 Docker，結果以失敗了結的經歷，多是我迄今爲止最大的管理敗績。
過早採用新技術的風險
幾年前，我發現技術炒做週期是這麼一回事：
「炒做週期中，市場先是對某種很棒的新事物有一段時期的誇大宣傳，鼓勵人們採用——直到技術逐漸真的普及開來，人們才發現新事物並無廣告中所描述的那麼神奇。而後這種新事物便會失寵，乃至被徹底丟棄或遺忘，直到它的成功所需的知識基礎成型爲止。」——Dick Dowdell
技術炒做週期
許多工程師在新技術誕生伊始的高峯期（也就是關注和討論最多的時期）錯誤地採用了它們。問題在於，不成熟的技術會有全新和未知的故障機制，而現有的解決方案並不會如此。
軟件工程團隊須要浪費大量時間尋找不那麼明顯的錯誤、查找文檔裏沒有的邊緣案例並重寫代碼來適應新技術。這就是六年前咱們嘗試採用 Docker 時發生的事情。咱們沒有足夠的資源來遍歷全部沒有文檔支持的特性和選項，並且 API 會隨着版本升級而不斷變化。
就算這些問題並無令你困擾，但早期採用者仍會承擔技術開發公司倒閉的風險。我記得有幾個朋友很早就用上了 RethinkDB，但到了開發它的公司於 2016 年關閉時他們大失所望。儘管它後來做爲一個社區維護項目又回來了，但讓你的應用程序數據庫陷入困境歷來都不是什麼好事情。
技術採用技巧
既然如此，若是新技術增長了太多沒必要要的風險，爲何咱們都沒有停留在 1990 年代的 Java 版本上呢？咱們如何才能避免落後太多，以致於連升級途徑都找不到呢？當咱們開始一個新項目時，咱們不該該使用最新的技術工具嗎？
針對這些有趣的問題，答案都是「取決於具體狀況」。
我已經開始爲在軟件工程團隊中採用新技術的策略制定一些經驗法則。請隨意使用這些內容，也能夠根據你的組織狀況作出調整或創建本身的規則集。
給人們時間進行實驗
我堅信能夠給員工一些時間來在工做中學習新事物。這爲他們提供了一種創造力的源泉，使他們保持領先，並能讓你嘗試一些業務永遠不會優先考慮的事情。若是一位工程師使用他的學習時間來證實咱們的應用程序中可使用某些新技術工具，那麼我會認真考慮此事。
「在將新技術用於產品以前，須要對新技術進行驗證……你必須作出結果。若是不這樣作，就是把產品推向了死亡之路。」——Andrew Orsich
保持一個默認技術棧
微服務的罪行之一是，它們鼓勵公司使用不一樣的編程語言來構建應用程序的不一樣部分。雖然經驗豐富的工程師可能會喜歡每週更換語言，但這會增長認知負擔，並讓新開發人員難以接受。當程序員選擇的語言不同時，團隊還會出現一些技術孤島。選擇一個技術棧做爲默認選項，僅在真正須要時才作擴展。
保持核心的可靠性
當你選擇嘗試新技術時，請先考慮將賭注限制在不過重要的功能上。當你基於 SQL 構建平臺時，很難採用某種新的、先進的數據庫，可是在臨時營銷站點上嘗試新的 UI 庫並不難。一旦在非關鍵任務中驗證了這項新技術後，你就能夠決定在整個核心應用程序中採用它。
在整個應用程序中採用新技術的風險級別
記住業務目標
與我合做過的最優秀的那些工程師始終會牢記「爲何」這一要點。他們在業務價值較低的應用程序部分中節約資源，而會花幾周時間來完善核心數據模型。做爲經理或團隊負責人，你必須隨時問本身爲何企業須要這種技術。若是某種新工具進入市場，你就必須判斷它會增長多少業務價值以及採用的成本。
結論
新技術並不壞。我喜歡嘗試使用新的框架和編程語言，可是做爲領導者，你必須在好奇心和業務目標之間取得平衡。人們很容易陷入未經驗證的新工具的泡沫中，所以，你應該制定標準來幫助你決定應該什麼時候嘗試新的工具。
最後，我是飄渺Jam，一名寫代碼的架構師，作架構的程序員，期待你的關注。我們下期見！
關注即送10個G的教學視頻喲！！！
本文分享自微信公衆號 - JAVA日知錄（javadaily）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。