作者：張凱峰
接地氣的技術(shù)雷達
ThoughtWorks在每年都會出品兩期技術(shù)雷達，這是一份關(guān)于技術(shù)趨勢的報告，它比起一些我們能在市面上見到的其他各種技術(shù)行情和預(yù)測報告，更加具體，更具可操作性，因為它不僅涉及到新技術(shù)大趨勢，比如云平臺和大數(shù)據(jù)，更有細致到類庫和工具的推介和評論，從而更容易落地。
這是2016年4月份的技術(shù)雷達全貌：
其中，自上次雷達發(fā)表以來新出現(xiàn)或發(fā)生顯著變化的技術(shù)以三角形表示，而沒有變化的技術(shù)則以圓形表示。每個象限的詳細圖表顯示各技術(shù)發(fā)生的移動。
技術(shù)雷達對于不同層級和水平的技術(shù)從業(yè)者，有可以從不同角度和分類進行解讀的可能。不管你是個人開發(fā)者，對于新工具和技術(shù)有執(zhí)著的追求，寄希望于從新工具和技術(shù)那里獲取改進每日工作的靈感，或者你是技術(shù)領(lǐng)導(dǎo)者需要針對自己的系統(tǒng)做技術(shù)選型，以及對未來技術(shù)趨勢的把握，技術(shù)雷達都會是一份很好的參考。
而如何解讀技術(shù)雷達就是變成一件很有意思的事情，解讀方式可以幫助我們更有效地利用它。下面會介紹幾種觀察技術(shù)雷達的不同角度。
在這里可以下載到最新版本的中文技術(shù)雷達。
手持一份技術(shù)雷達，更新技能和工具
技術(shù)雷達在四個象限（技術(shù)，工具，平臺，語言和框架）中，布滿了大量由ThoughtWorks技術(shù)專家們發(fā)現(xiàn)的，可以極大改善開發(fā)效率和品質(zhì)的條目。它們大多數(shù)會分布在每個象限的試驗和評估區(qū)域。
這些條目多具備創(chuàng)新和極客精神，可以很大程度上改善個人開發(fā)者的開發(fā)興趣，保持對于新技術(shù)和技能的敏感度。
下面是兩個例子：
Gauge是一個輕量級的跨平臺測試自動化工具。技術(shù)規(guī)格由自由的Markdown語法寫成，因此，測試用例可以用業(yè)務(wù)語言而不是使用通常的 ‘given-when-then’ 這種具有局限性的格式來描述。不同語言和IDE的支持以插件的形式添加到核心實現(xiàn)中這使得測試人員能夠與團隊一起使用同樣的支持自動完成、重構(gòu)等功能的IDE。同時，這個ThoughtWorks出品的開源工具天生就能夠并行執(zhí)行所有支持平臺的測試。
Aurelia采用最新的Javascript:ECMAScript 2016標(biāo)準(zhǔn)開發(fā)而成，被認(rèn)為是下一代JavaScript客戶端開發(fā)框架。Aurelia的作者Rob Eisenberg是Durandal之父，離開Angular2.0核心團隊之后全力打造了Aurelia。Aureliarelia最了不起的是它的高度模塊化，包含了許多小型庫，可以非常方便的進行定制化開發(fā)。Aurelia遵循約定優(yōu)于配置的理念，而且其約定恰到好處，很容易進行模塊的產(chǎn)生和使用。Aurelia有一個龐大的開發(fā)社群，它的官網(wǎng)還提供了非常好的入門文檔。
開發(fā)者把玩并品味，將新工具和技術(shù)應(yīng)用到手頭的軟件開發(fā)工作中，可以給日復(fù)一日、陳舊乏味的遺留系統(tǒng)帶來新的氣象，而成就感也就伴隨而來。
如果對于已經(jīng)處在采用（非常推薦）區(qū)域的技術(shù)條目，如果開發(fā)者仍然覺得陌生，那這也許就是自己對技術(shù)的敏感度在下降的征兆了。比如Docker和React.js。
停止對不推薦技術(shù)的過度投資
開發(fā)者會覺得有一些技術(shù)和工具方興未艾，依然趁手，但技術(shù)雷達已經(jīng)將它們放入了暫緩區(qū)域（停止推薦），開始唱衰，這樣的態(tài)度可以給開發(fā)者一些前瞻性的警示。
過度地投資在不被看好前景的技術(shù)上，勢必會拖累開發(fā)的節(jié)奏和進度，跟不上市場的步伐，開發(fā)者需要的是擁抱更具市場前沿性的工具和技術(shù)。
比如這一期的技術(shù)雷達對于單一CI（持續(xù)集成）實例的擔(dān)憂：
因為只有一個統(tǒng)一的配置和監(jiān)控點，但是在一個組織中多個團隊共享一個臃腫的CI會導(dǎo)致很多的問題。構(gòu)建超時、配置沖突和巨型構(gòu)建隊列等類似問題出現(xiàn)得越來越頻繁。這種缺陷導(dǎo)致的單點失敗會造成多個團隊工作的中斷。要認(rèn)真考慮在這些陷阱和保持單點配置之間找到一個平衡點。而雷達的建議是，由各個團隊分布式地管理自己獨立的CI。
還有一個很顯著的例子是關(guān)于雷達對于Gitflow暫緩的態(tài)度，而這里有一篇很好的文章：Gitflow有害論，來自我的同事劉尚奇。
看技術(shù)演進動態(tài)
除了可以靜態(tài)地看一份最新的技術(shù)雷達，我們?nèi)绻麑φ毡容^瀏覽最近幾期技術(shù)雷達中一些技術(shù)點的動態(tài)演進趨勢，這會是一個更加有趣的體驗。一方面也可以培養(yǎng)開發(fā)者自身對位技術(shù)未來趨勢的把控力，另外一方面也可以印證技術(shù)雷達的前瞻性和可靠性，
這樣動態(tài)形式看技術(shù)雷達，大致可以分下面兩類方式：
單看某個技術(shù)點的演進
一個典型例子可以是技術(shù)雷達關(guān)于AngularJS的態(tài)度：
雖然我們使用AngularJS成功交付了很多項目，并且也能看到大型企業(yè)中越來越多的項目采用該框架，但是我們決定在這個版本的技術(shù)雷達將Angular移回“評估”。這個改動是為了讓大家注意：React.js和Ember也有很不錯的可選性，Angular從1.0到2.0的遷移過程充滿不確定，同時我們發(fā)現(xiàn)一些組織在使用這個框架時并沒有認(rèn)真思考單頁應(yīng)用是否適合他們的需要。為此我們進行了激烈的內(nèi)部辯論，但是可以肯定的是，同時使用雙向綁定與不一致狀態(tài)管理模式會讓代碼變得過于復(fù)雜。另外我們相信，相比于嘗試移除一個固有框架，更好的方式是通過仔細的設(shè)計，在外層使用Redux或者Flux，來解決這些問題。
目前在前端框架方面，技術(shù)雷達的新寵是React.js。
另外更加明顯的在技術(shù)雷達上不斷演進的例子是Gradle和SpringBoot。比如下面是技術(shù)雷達的歷次版本對于SpringBoot的推介態(tài)度：
從技術(shù)雷達的主題展開看
技術(shù)雷達開頭的”最新動態(tài)“旨在展現(xiàn)當(dāng)期雷達中最為引人注目并值得關(guān)注的幾個技術(shù)或者主題。比如下面是最新這一期技術(shù)雷達的主題截圖：
由主題內(nèi)容開始，去尋找當(dāng)期技術(shù)雷達中對于該主題的展開論述，在各個象限內(nèi)找到對其有支持和補充的具體技術(shù)點，可以在開發(fā)者腦中繪制出一份更加完整的關(guān)于這個主題的現(xiàn)狀和趨勢來。
比如對于微服務(wù)這個技術(shù)，我們可以看到在技術(shù)雷達中，有這樣一些技術(shù)、工具或者平臺對于微服務(wù)架構(gòu)的支撐：
而跳出單份技術(shù)雷達，開發(fā)者可以留意到，連續(xù)兩三期的技術(shù)雷達都可能在針對同一技術(shù)，做主題性質(zhì)的連續(xù)闡述，來闡釋這一技術(shù)點在雷達中的重要性和演進的程度。
再比如微服務(wù)，它在技術(shù)雷達中的演進過程是，2012年3月雷達建議開始評估微服務(wù)，2012年10月則建議可以在系統(tǒng)中試驗微服務(wù)架構(gòu)，直到2015年1月出現(xiàn)Microservice Envy（微服務(wù)羨慕嫉妒恨），雷達建議暫緩實施微服務(wù)。
可以看見，對于微服務(wù)，雷達的態(tài)度是推薦而且敏感的。跟隨雷達，開發(fā)者可以提前時間預(yù)見到自己可能遭遇的坑，以及會有相應(yīng)的解決方案。
同樣，不止于微服務(wù)，我們?nèi)匀豢梢哉业筋愃七@樣的主題技術(shù)在雷達中的位置和全貌。
比如技術(shù)雷達對于安全領(lǐng)域的關(guān)注，在最新一期中，除了積極推薦采用的威脅建模方法外，雷達還提到了一下這些技術(shù)點，從證書管理、安全規(guī)范、漏洞檢查、機密信息訪問等方面，提供了一些推薦試驗或評估的條目：
OWASP的ASVS（應(yīng)用程序安全標(biāo)準(zhǔn)）
如數(shù)家珍，開始做技術(shù)選型
現(xiàn)在開發(fā)一個典型的Web應(yīng)用，前端+后端可以有很多技術(shù)的選擇，前端AngularJS方興未艾，ReactJS已經(jīng)異軍突起，而對后端進行架構(gòu)和選型，可以挑選的空間則更大，我們不得不在業(yè)務(wù)和技術(shù)采納，甚至加上遺留系統(tǒng)之間，做更多的權(quán)衡和把握。
比如如果我們需要嘗試微服務(wù)架構(gòu)，并且碰巧身處Spring生態(tài)，那么SpringBoot會是更優(yōu)的選擇：
很多的工作已經(jīng)通過使用SpringBoot來降低復(fù)雜度和依賴， 這在很大程度上緩解了我們以前的保留意見。如果你在Spring的生態(tài)系統(tǒng)中并正在走向微服務(wù)架構(gòu)，SpringBoot就是當(dāng)下最好的選擇。而那些不在Sping生態(tài)環(huán)境中項目，Dropwizard也值得認(rèn)真考慮 。
我的同事佟達對關(guān)于如何采用Python作為大數(shù)據(jù)全棧式開發(fā)語言的論述，同樣精彩。他就云基礎(chǔ)設(shè)施、DevOps、網(wǎng)絡(luò)爬蟲、數(shù)據(jù)處理四個方面，細數(shù)Python技術(shù)棧的選擇，對于打造一個大數(shù)據(jù)處理平臺的可能，信手拈來。
就像只要會JavaScript就可以寫出完整的Web應(yīng)用，只要會Python，就可以實現(xiàn)一個完整的大數(shù)據(jù)處理平臺。
期待更多
ThoughtWorks技術(shù)雷達是一份不限行業(yè)，技術(shù)中立的前瞻性技術(shù)報告。它預(yù)測技術(shù)趨勢，小到一個工具和類庫，大到平臺和架構(gòu)，而我們已經(jīng)在不斷見證事實的發(fā)生。本文提供了一些可能有幫助的觀察技術(shù)雷達的視角，你還有更有幫助的視角嗎？
原文發(fā)表于：解讀ThoughtWorks技術(shù)雷達
