解讀ThoughtWorks技術雷達的正確姿勢

接地氣的技術雷達

ThoughtWorks在每年都會出品兩期技術雷達，這是一份關於技術趨勢的報告，它比起一些我們能在市面上見到的其他各種技術行情和預測報告，更加具體，更具可操作性，因為它不僅涉及到新技術大趨勢，比如雲平台和大數據，更有細緻到類庫和工具的推介和評論，從而更容易落地。

這是2016年4月份的技術雷達全貌：

其中，自上次雷達發表以來新出現或發生顯著變化的技術以三角形表示，而沒有變化的技術則以圓形表示。每個象限的詳細圖表顯示各技術發生的移動。

技術雷達對於不同層級和水平的技術從業者，有可以從不同角度和分類進行解讀的可能。不管你是個人開發者，對於新工具和技術有執著的追求，寄希望於從新工具和技術那裡獲取改進每日工作的靈感，或者你是技術領導者需要針對自己的系統做技術選型，以及對未來技術趨勢的把握，技術雷達都會是一份很好的參考。

而如何解讀技術雷達就是變成一件很有意思的事情，解讀方式可以幫助我們更有效地利用它。下面會介紹幾種觀察技術雷達的不同角度。

在這裡可以下載到最新版本的中文技術雷達。

手持一份技術雷達，更新技能和工具

技術雷達在四個象限（技術，工具，平台，語言和框架）中，布滿了大量由ThoughtWorks技術專家們發現的，可以極大改善開發效率和品質的條目。它們大多數會分布在每個象限的試驗和評估區域。

這些條目多具備創新和極客精神，可以很大程度上改善個人開發者的開發興趣，保持對於新技術和技能的敏感度。

下面是兩個例子：

Gauge是一個輕量級的跨平台測試自動化工具。技術規格由自由的Markdown語法寫成，因此，測試用例可以用業務語言而不是使用通常的 『given-when-then』 這種具有局限性的格式來描述。不同語言和IDE的支持以插件的形式添加到核心實現中這使得測試人員能夠與團隊一起使用同樣的支持自動完成、重構等功能的IDE。同時，這個ThoughtWorks出品的開源工具天生就能夠並行執行所有支持平台的測試。

Aurelia採用最新的Javascript:ECMAScript 2016標準開發而成，被認為是下一代JavaScript客戶端開發框架。Aurelia的作者Rob Eisenberg是Durandal之父，離開Angular2.0核心團隊之後全力打造了Aurelia。Aureliarelia最了不起的是它的高度模塊化，包含了許多小型庫，可以非常方便的進行定製化開發。Aurelia遵循約定優於配置的理念，而且其約定恰到好處，很容易進行模塊的產生和使用。Aurelia有一個龐大的開發社群，它的官網還提供了非常好的入門文檔。

開發者把玩並品味，將新工具和技術應用到手頭的軟體開發工作中，可以給日復一日、陳舊乏味的遺留系統帶來新的氣象，而成就感也就伴隨而來。

如果對於已經處在採用（非常推薦）區域的技術條目，如果開發者仍然覺得陌生，那這也許就是自己對技術的敏感度在下降的徵兆了。比如Docker和React.js。

停止對不推薦技術的過度投資

開發者會覺得有一些技術和工具方興未艾，依然趁手，但技術雷達已經將它們放入了暫緩區域（停止推薦），開始唱衰，這樣的態度可以給開發者一些前瞻性的警示。

過度地投資在不被看好前景的技術上，勢必會拖累開發的節奏和進度，跟不上市場的步伐，開發者需要的是擁抱更具市場前沿性的工具和技術。

比如這一期的技術雷達對於單一CI（持續集成）實例的擔憂：

因為只有一個統一的配置和監控點，但是在一個組織中多個團隊共享一個臃腫的CI會導致很多的問題。構建超時、配置衝突和巨型構建隊列等類似問題出現得越來越頻繁。這種缺陷導致的單點失敗會造成多個團隊工作的中斷。要認真考慮在這些陷阱和保持單點配置之間找到一個平衡點。而雷達的建議是，由各個團隊分散式地管理自己獨立的CI。

還有一個很顯著的例子是關於雷達對於Gitflow暫緩的態度，而這裡有一篇很好的文章：Gitflow有害論，來自我的同事劉尚奇。

看技術演進動態

除了可以靜態地看一份最新的技術雷達，我們如果對照比較瀏覽最近幾期技術雷達中一些技術點的動態演進趨勢，這會是一個更加有趣的體驗。一方面也可以培養開發者自身對位技術未來趨勢的把控力，另外一方面也可以印證技術雷達的前瞻性和可靠性，

這樣動態形式看技術雷達，大致可以分下面兩類方式：

單看某個技術點的演進

一個典型例子可以是技術雷達關於AngularJS的態度：

雖然我們使用AngularJS成功交付了很多項目，並且也能看到大型企業中越來越多的項目採用該框架，但是我們決定在這個版本的技術雷達將Angular移回「評估」。這個改動是為了讓大家注意：React.js和Ember也有很不錯的可選性，Angular從1.0到2.0的遷移過程充滿不確定，同時我們發現一些組織在使用這個框架時並沒有認真思考單頁應用是否適合他們的需要。為此我們進行了激烈的內部辯論，但是可以肯定的是，同時使用雙向綁定與不一致狀態管理模式會讓代碼變得過於複雜。另外我們相信，相比於嘗試移除一個固有框架，更好的方式是通過仔細的設計，在外層使用Redux或者Flux，來解決這些問題。

目前在前端框架方面，技術雷達的新寵是React.js。

另外更加明顯的在技術雷達上不斷演進的例子是Gradle和SpringBoot。比如下面是技術雷達的歷次版本對於SpringBoot的推介態度：

從技術雷達的主題展開看

技術雷達開頭的」最新動態「旨在展現當期雷達中最為引人注目並值得關注的幾個技術或者主題。比如下面是最新這一期技術雷達的主題截圖：

由主題內容開始，去尋找當期技術雷達中對於該主題的展開論述，在各個象限內找到對其有支持和補充的具體技術點，可以在開發者腦中繪製出一份更加完整的關於這個主題的現狀和趨勢來。

比如對於微服務這個技術，我們可以看到在技術雷達中，有這樣一些技術、工具或者平台對於微服務架構的支撐：

而跳出單份技術雷達，開發者可以留意到，連續兩三期的技術雷達都可能在針對同一技術，做主題性質的連續闡述，來闡釋這一技術點在雷達中的重要性和演進的程度。

再比如微服務，它在技術雷達中的演進過程是，2012年3月雷達建議開始評估微服務，2012年10月則建議可以在系統中試驗微服務架構，直到2015年1月出現Microservice Envy（微服務羨慕嫉妒恨），雷達建議暫緩實施微服務。

可以看見，對於微服務，雷達的態度是推薦而且敏感的。跟隨雷達，開發者可以提前時間預見到自己可能遭遇的坑，以及會有相應的解決方案。

同樣，不止於微服務，我們仍然可以找到類似這樣的主題技術在雷達中的位置和全貌。

比如技術雷達對於安全領域的關注，在最新一期中，除了積極推薦採用的威脅建模方法外，雷達還提到了一下這些技術點，從證書管理、安全規範、漏洞檢查、機密信息訪問等方面，提供了一些推薦試驗或評估的條目：

• 內容安全策略
• OWASP的ASVS（應用程序安全標準）
• Let』s Encrypt
• OWASP Dependency-check
• Gitrob
• HashiCorp Vault

如數家珍，開始做技術選型

現在開發一個典型的Web應用，前端+後端可以有很多技術的選擇，前端AngularJS方興未艾，ReactJS已經異軍突起，而對後端進行架構和選型，可以挑選的空間則更大，我們不得不在業務和技術採納，甚至加上遺留系統之間，做更多的權衡和把握。

比如如果我們需要嘗試微服務架構，並且碰巧身處Spring生態，那麼SpringBoot會是更優的選擇：

很多的工作已經通過使用SpringBoot來降低複雜度和依賴， 這在很大程度上緩解了我們以前的保留意見。如果你在Spring的生態系統中並正在走向微服務架構，SpringBoot就是當下最好的選擇。而那些不在Sping生態環境中項目，Dropwizard也值得認真考慮 。

我的同事佟達對關於如何採用Python作為大數據全棧式開發語言的論述，同樣精彩。他就雲基礎設施、DevOps、網路爬蟲、數據處理四個方面，細數Python技術棧的選擇，對於打造一個大數據處理平台的可能，信手拈來。

就像只要會JavaScript就可以寫出完整的Web應用，只要會Python，就可以實現一個完整的大數據處理平台。

期待更多

ThoughtWorks技術雷達是一份不限行業，技術中立的前瞻性技術報告。它預測技術趨勢，小到一個工具和類庫，大到平台和架構，而我們已經在不斷見證事實的發生。本文提供了一些可能有幫助的觀察技術雷達的視角，你還有更有幫助的視角嗎？

?
推薦閱讀：