ThoughtWorks 技術雷達（2013年5月）

ThoughtWorks技術雷達（2013年5月）

做者ThoughtWorks技術戰略委員會 發佈於 六月 25, 2013| 討論

• 新浪微博 騰訊微博 豆瓣網 Twitter Facebook linkedin 郵件分享 更多 12
• 稍後閱讀
• 個人閱讀清單

技術

多年來，團隊和組織都已經看到了圍繞技術學科進行專業細分的危險性。當咱們就高級應用聽取專家的建議時，開發人員至少應當瞭解用戶界面，數據庫和數據科學等業界新寵的基礎知識。當高級應用須要深刻的專業知識時，咱們要在全部開發人員使用基礎統計分析理論和工具的領域，推進協做分析與數據科學，以此作出更好的決策，並在事情愈趨複雜時，開展與專家的密切合做。

技術趨勢已經衝破了本來保護着企業IT網絡的圍牆，成爲沒有邊界的企業。員工們頻繁使用本身的消費設備經過雲服務和Web API訪問企業數據，而企業每每對此並不知情。隨着設備不斷擴散以及更多的應用程序遷移到雲端，迫使企業從新考慮數據訪問和網絡安全的基本假設。

在雲端搭建的開發環境意味着開發的基礎設施可以外包，開發人員只須要一臺筆記本電腦和網絡鏈接。經過組合使用最佳的服務，如GitHub的私有資料庫加上雲端的Snap CI持續集成環境，你的團隊也許永遠都再也不須要爲自建IT基礎設施而勞神了。

廉價或免費的視頻會議工具，質量正在不斷改善，選擇也愈來愈多，讓分佈式團隊有了一種全新的工做方式。即使團隊分散在各地，全天候（Always-on）視頻連通也能夠幫助創建一種虛擬的臨場感。事實上，這已經成爲咱們部分離岸交付中心的標配。咱們還看到像ScreenHero這樣的屏幕共享工具已經開始被普遍用於遠程結對編程。但咱們也必須警戒尋找銀彈消除物理上同處一地的需求，畢竟沒有什麼能夠替代面對面溝通時所產生的相互理解和情感交流。

一旦開始使用一件全新的工具，管理不一樣環境的部署，或者嘗試着理解應用程序的行爲爲什麼在不一樣環境表現各異，對應用的配置就會成爲痛苦的根源。做爲最小化應用配置的擁躉，咱們正嘗試去保證應用能在最小配置下可以正常工做。

多數虛擬化技術都提供了經過加載鏡像啓動虛擬機的方法。在構建管道中要儘早建立虛擬機鏡像做爲構建產物, 隨着它經過後續的測試套件對其進行提高，如此就能實現從測試環境到產品環境機器上的可靠部署 。此技術剔除了致使snowflake server*（註釋）反模式的多數緣由。

藍綠部署（Blue-green deployment）是一種執行軟件升級的模式。首先，將最新版本的應用部署到一個和當前產品環境徹底同樣的應用棧副本中。這樣，當新版本的應用經過了相應的測試並獲得了業務上的許可後，訪問就能夠被瞬間切換這個新版本的應用上。儘管這不是一項新技術，但基礎設施自動化和雲端資源使它值得被從新考慮。

之前，像Chef和Puppet這樣的工具都缺少對Windows的支持，致使構建簡單的基礎設施自動化任務都須要大量的Powershell腳本。因此，想要使Windows到達和Unix同樣的自動化水平可謂困難重重。不過在過去的一年裏，Chef和Puppet對Windows的支持獲得了很大改善。這種支持與強大的PowerShell相結合，使得Windows基礎設施自動化極爲可行。

HTML5存儲，也被稱爲本地存儲或Web存儲，是一種在現代瀏覽器裏存儲客戶端數據的機制，其中也包括iOS和Android移動瀏覽器。 在幾乎全部狀況下，咱們都建議使用HTML5存儲，而不是cookie 。 HTML5存儲最多可容納5MB的數據，而cookie則被限制在4KB。 Cookie的數據在每一次請求中都會被髮送，這會拖慢你的應用程序，而且有可能將數據暴露於不安全的HTTP鏈接中。 與此相反，HTML5存儲只須要由瀏覽器來保證數據安全。 Cookie則只應該用來保存像session id這樣的簡單數據。

使用Promise進行異步編程是一項古老的技術，也被稱爲futures。因爲JavaScript在客戶端和服務器端的的普遍使用，它又再次獲得了關注。這項技術消除了深層嵌套回調、標誌位和輪詢，同時獲得了像jQuery庫的一等支持。若是項目涉及到很是複雜的JavaScript代碼庫，團隊就應該利用這項技術。

捕獲客戶端JavaScript錯誤，已經被咱們的交付團隊用來識別與瀏覽器或插件配置相關的影響用戶體驗的問題。在過去一年中，一些服務提供商業已開始對這一需求提供支持。除了將這些錯誤儲存於應用數據存儲中，一些Web應用還會將這些錯誤記錄到網絡分析工具，或像New Relic這樣監測工具中，以減輕存儲的需求。

隨着HTML5模糊了傳統本地應用和Web應用程序之間的界線，咱們正開始試驗移動設備上的持續交付。 如TestFlight服務可以讓你在一天內屢次部署本地應用程序到實際設備上。對於所有或部分基於HTML5的應用程序，能夠直接部署修改，而無需嚮應用商店提交一個新的應用。若是你的組織有企業內應用程序商店，就能夠輕鬆的發佈應用。咱們注意到，當移動設備上的持續交付技術實現不斷改進時，測試實踐則相對落後。要取得成功，你須要更加專一於自動化測試，以確保應用被部署到設備上時可以正常工做。

咱們愈來愈多的看到移動應用在開發和測試過程當中工做良好，但在發佈出去後卻問題多多。移動網絡的移動測試（Mobile testing on mobile networks）揭示了應用是如何在不一樣條件下運行的。你可能須要測試3G，LTE，或者故意使用一個訪問超載的糟糕的WiFi網絡。先獲取目標環境下的網絡性能，而後用延遲和丟包誘導工具去模擬相同的環境。 此外，使用像Wireshark這樣的工具去檢測你的設備和軟件到底如何使用網絡，有時也是必要的。

NoSQL數據存儲正繼續成爲主流，但團隊須要充分認識到對遷移數據庫到NoSQL的需求。特別是使用隱式或動態schema，你可能會隨着時間的推移須要從新配置數據。這裏提供了幾種方法：好比在部署新版本應用時進行顯式地遷移，或者經過代碼在加載和處理文檔時進行動態遷移。

失敗的測試揭示了產品代碼中的bug。然而，針對其餘屬性進行分析性測試則能夠揭示一些有趣的信息。 一個簡單的例子是監測頻繁失敗的測試，而後在構建管道中儘早運行它們，從而快速獲得反饋。同理，跟蹤其餘屬性，如測試執行時間和耗時測試的比例，也能夠爲達成快速測試提供可操做的指標。

在之前的雷達中，咱們曾經建議延長自動化驗收測試的週期，在咱們稱之爲語義監控（semantic monitoring）的階段，不斷在產品環境中運行這些測試。 如今咱們仍然相信，這是一項使團隊能夠提早預測狀況的重要技術。但如今, 尤爲是在初創公司中, 咱們還看到這種方法的一個變體, 就是在減小測試次數的同時，增長監控與自動報警。這使關注點從避免可預見的問題轉移到對全部問題減小平均的恢復時間。

雖然單元測試和驗收測試被普遍接受並做爲標準的開發實踐，但這一趨勢尚未延伸到性能測試領域。目前，經常使用的測試工具促使測試人員養成編寫一次性代碼, 對點擊進行腳本化的心態。 給予性能測試一等公民待遇，能夠創造更好的測試，涵蓋了更多的功能，引導出更好的工具來建立和運行性能測試，從而使得測試套件能夠被維護，並能自我測試。

平臺

PostgreSQL 正在逐漸成爲SQL數據庫中的NoSQL選擇。版本9.2支持存儲JSON格式的數據，並在其之上提供完備的查詢功能。另外，PostgreSQL還提供了容許用戶以鍵值對（key/value pair）的形式存儲和查詢數據的擴展。該擴展讓你能夠直接利用穩定的數據庫底層存儲和事務的能力， 而無需綁定在關係數據模型上.對於那些但願同時開發SQL和NoSQL應用，卻又傾向於使用一套他們熟知的可靠基礎設施的開發者而言，提供這一特性就再理想不過了。

網站的訪問量即便再低，其產生的數據量也多是巨大的。一旦你把各類分析結果，業務圖表， 統計數據，用戶資料以及對多設備的支持囊括進來，數據量可能會大到不可思議。許多組織使用數據倉庫來存儲從各部門收集上來的數據。這樣作的挑戰是數據倉庫會變成一座「數據森林」。即便是獲取及時的業務圖表也已變成一種挑戰，更別提在整個數據集上運行探索性查詢了。而基於BigQuery之類的雲技術對此會有幫助。它們即時付費的模式和能夠運行任意查詢的能力使你無需購買特殊的軟硬件也能得到對數據的全面掌控。數據驅動的商業模式應該將數據送到決策者手中, 而不是隱藏在技術障礙和官僚主義中。

對於適用文檔數據庫模型的問題來講，MongoDB是當下最流行的選擇. 除了易於使用和提供高可靠性的技術實現以外，開發社區及整個生態系統對其成功也貢獻良多。咱們也據說了一些團隊抵受不住MongoDB流行的誘惑而產生了問題，好比並不適用文檔數據庫的應用, 又或者團隊沒有充分理解其內在的複雜性。然而若能用對， MongoDB已經在不少項目中證實了本身。

Redis 已經在多個ThoughtWorks項目中被證實是有用的工具。它被用做結構化的緩存或者跨越多個國家的分佈式數據存儲。

Hadoop最初的架構基於水平擴展數據，垂直擴展元數據的模式。 儘管slave節點能夠從容的進行數據的存儲和處理，管理元數據的master倒是瓶頸，同時也限制了規模化網絡的使用。Hadoop 2.0 從新設計了HDFS和Map Reduce框架的架構，以此來解決這些問題。如今，HDFS的命名空間能夠經過使用同一個集羣的多個name nodes來聯合在一塊兒，而且部署爲高可用性(HA)模式。 MapReduce也被YARN取代了。YARN解耦了集羣的資源管理和任務的狀態管理，而且經過JobTracker消除了伸縮性和性能問題. 最重要的是，這些變化鼓勵在Hadoop集羣上開發除了MapReduce以外的分佈式計算模型。

在過去的一年中，咱們發現採用Elastic Search（彈性搜索）做爲開源的搜索平臺呈逐步上升趨勢。Elastic Search基於Apache Lucene, 是一個可擴展的，多租戶的， 支持水平伸縮的搜索解決方案。它容許索引複雜數據, 並可經過JSON獲取。它支持從集羣, 故障轉移及備份中自動恢復各節點。Elastic Search能夠經過基於插件系統的REST API來擴展，它提供了一個優雅的操做模型, 容許添加新功能, 或者改變現有行爲。圍繞着Elastic Search的社區是很是活躍的。一個證據就是已經開發出了包括Java、 C#、 Ruby 和 JavaScript 在內的多個客戶端類庫。

Node.js 是一個輕量級web容器。它在開發微服務, 移動服務端以及單頁面web應用方面都是極好的選擇。由於其自然的異步特性, 開發人員能夠經過使用promise類庫來簡化應用代碼。 隨着在node.js社區promise應用的成熟, 咱們指望看到更多爲node.js開發的應用。 對那些不肯在產品環境中嘗試node.js的團隊, 用node.js來實現一些開發任務仍然值得考慮, 好比在瀏覽器以外運行JavaScript測試, 或者從相似CoffeeScript, SASS和LESS之類的工具中生成靜態web內容。

Zepto.js 是一個輕量級的JavaScript類庫。它的API與JQuery相同, 但並不是100%兼容.因其壓縮顯著的文件大小, Zepto在開發響應式web應用方面很有競爭力。

PhoneGap, 如今叫 Apache Cordova, 容許你使用HTML, CSS和JavaScript 來開發跨平臺的移動應用。它經過一組JavaScript API對平臺特定的本地代碼作了抽象, 同時還保持了不一樣移動平臺之間的一致性。Cordova支持很是多的平臺, 包括iOS、Android、 Blackberry、 Windows Phone 以及 WebOS。

在雲存儲和雲計算領域, 儘管AWS還在持續的增長功能, Rackspace Cloud 卻悄悄發展爲一名不可忽視的競爭者。部分用戶會很是看重Rackspace更加周到的客戶支持, 以及混合多種傳統託管模型的能力。 咱們並不爲之而感到激動人心，由於Rackspace是咱們的客戶, 咱們在參與該平臺的開發過程當中已經收穫了許多樂趣。咱們在另外多個客戶的項目中已經成功地應用了Rackspace Cloud, 目前正期待着它能輻射到更多的地區。

開源OpenStack項目的發展可謂蒸蒸日上, 在最近幾個月，它已經逐漸成爲部署私有云的不二選擇。 許多原來致使OpenStack難以使用以及運行不穩定的問題都獲得瞭解決. 新功能也一直都在增長。顯然，OpenStack聯盟包括它的成員如Rackspace，Redhat，HP等都在不斷爲其添磚加瓦, 並以此做爲自有的基於OpenStack的雲服務基礎。

在去年全球售出的手機中, 58%實際上是老式的功能手機, 而非智能手機。 在不少發展中國家, 這一比例甚至更高。若是你的客戶須要你爲這些地區開發應用, 你須要考慮到這些限制。這些手機使用SMS和USSD做爲用戶界面。SMS是存在已久的發送消息的技術, 而USSD容許你經過安全會話來發送SMS之類的消息。你應該把SMS和USSD看作另一個UI和UX的平臺, 給予它們一等公民的待遇。

Vumi是一個可伸縮的開源的消息引擎。 它在移動設備上經過一些廉價的方式來完成通訊。 Vumi幫助公司和它們的客戶, 醫療服務機構和它們的病人, 政府和市民, 以及更多的團隊之間經過SMS , IM 和 USSD進行交互. Vumi與電信公司進行了集成, 使你可以很容易的基於它構建應用, 而你只須要向運營商支付通訊費。

「企業級」商業軟件包提供的功能, 和實際須要的功能之間的差距正在拉大。這對面向互聯網的應用來講更是如此。那些真正可以擴展自如的創新方案, 易於支持的現代技術如持續交付等, 都是實踐者寫給實踐者的。它們肇始於許多互聯網規模的公司, 然後做爲開源軟件獲得了提煉。龐大的企業解決方案一般會阻礙高效的交付，由於這些方案通過長久累積，具備臃腫而繁瑣的許可限制；它驅動出來的功能集來自於檢查列表，依靠假想出來的脫離多數團隊開發現實的需求。

工具

在上期的技術雷達中，咱們談到的嵌入式servlet容器。現在，這已經在咱們的項目中普遍採用。像 SimpleWeb 和 Webbit 這樣的工具在追求簡潔和嵌入式的方向上更進一步，提供了未實現 Java Servlet 規範的原生HTTP 服務器功能。同時，最流行的 Java 應用服務器 Tomcat 在嵌入式安裝中應用的逐漸增多，以及微軟爲 .NET 框架提供的自託管服務器，都增強了這一趨勢。

D3 做爲一個用來在瀏覽器上建立豐富可視化效果應用的 JavaScript 庫，也在持續得到更多的關注。此前，使用 D3多少 顯得有點底層， 比起那些更簡單更有針對性的庫，它須要更多的工做量完成經常使用的可視化效果。自從發佈了上一次技術雷達，隨着諸如用於圖表的 Rickshaw 以及用於在瀏覽器中進行數據探索的 Crossfilter 等庫的出現，使得 D3 比之前更容易使用了。

咱們看到一些 JavaScript 框架正在擁抱基於瀏覽器的模板化的趨勢，它們把更多的佈局工做轉移到客戶端來作。雖然這種方法在不少狀況下頗有效，但它也會引入一些涉及緩衝、性能和搜索方面的運營問題。咱們認爲在使用這些工具前，須要仔細對這些工具進行評估，以確保知足目標部署環境的要求。

經過把 IObservables 和 IObservers 放到與 IEnumerables 和 IEnumerators 同等的地位上，.NET 上的響應式編程框架 Rx 容許開發者經過observable事件流的通用底層抽象，使用已有的 LINQ（Language INtegrated Query） 操做符，來查詢和編寫異步操做和基於事件的代碼。

微軟也發佈了 RxJS 庫把響應式編程的好處帶到 JavaScript 中。整個 Rx 框架的開源，也使其在 Windows 富客戶端應用和單頁面 JavaScript 應用中發揮更大的做用。

一些 ThoughtWorks 的團隊特別提到 Ruby 的 HTTP 客戶端類庫 Faraday 的實用性。它爲各類適配器提供了通用的接口，而且和Rack 中間件有良好的集成。

針對第三方庫的包管理系統繼續在全部平臺上得到承認，也都在不斷添加新的功能。咱們最近把 NuGet 和 Chocolatey NuGet 列入到技術雷達，也證明了這個重要的敏捷工程實踐的先進性。

基於Windows的基礎自動化應該採用，然而仍然要比在 Unix 上進行基礎設施自動化要困可貴多。Chef 和 Puppet 正在增長對 Windows 基礎設施自動化的支持，同時也有正在研發中的像Octopus這種專門針對 Windows 的解決方案。Octopus 能夠在自動部署 ASP.NET 應用程序和 Windows 服務時減小對 PowerShell 的依賴。它也能夠與 NuGet 和 TeamCity 一塊兒使用，以此建立一個完整的構建、打包、部署管道。

Puppet 和 Chef 都須要處理社區針對通用服務和任務而共享的module和manifest。Puppet Forge 和 Chef的Cookbook 資料庫能在必定程度上解決這個問題，但結果是人們老是複製和粘貼這些腳本到本身的代碼中，這樣他們就不能享受到最近的錯誤修正和改進的好處。Puppet-librarian 和 Chef-librarian 經過讓你更容易地聲明本身的模塊依賴關係，試圖解決這個問題。其作法包括從這些社區網站取得已知版本的代碼。

在分佈式系統上的依賴關係管理很是複雜，這也是愈來愈多人在遷移到細粒度的微服務（micro-services）時所須要面對的問題。來自 Netflix 的 Hystrix 是一個實現了處理各類下游故障模式的 Java 類庫，它提供鏈接的實時監控、緩存和批處理機制，以更有效地管理服務間的依賴關係。

不須要應用程序商店，TestFlight 和 HockeyApp讓你可以管理移動應用程序的部署，讓用戶測試更容易。它們提供了崩潰報告和實際數據分析的能力。HockeyApp 支持 iOS、Andriod 和 Windows Phone 平臺，而 TestFlight 只支持 iOS 和 Android 平臺。咱們已經成功地使用這兩種工具來幫助移動應用程序的發佈。這顯然是一個快速發展的領域。

Frank是一個開源庫，可使用Cucumber 編寫iOS 的功能測試，並在遠程設備上執行。

之前在 iOS上，驗收測試驅動開發很是麻煩，該庫填補了一項重要的空白。

UIAutomator容許測試時對用戶界面組件的細粒度控制，以及爲在多個設備上的測試提供幫助，所以被認爲是Android 用戶界面測試方面最有前途的工具。

隨着具備多種外形因素和像素密度的設備的興起，呈現全尺寸高品質圖標的問題已經變得很是重要。圖標字體利用瀏覽器對WebFonts和SVG的支持，而不是使用縮放圖像或維護不一樣的圖標集，解決了這個問題。但當大量使用 SVG 時，須要注意移動設備的功耗問題和舊設備上的性能問題。

隨着咱們構建的系統比以往涉及愈來愈多細粒度服務，分佈在愈來愈多的機器上，如何得到集中的信息以便更方便地識別和解決問題，比以往任什麼時候候都更具挑戰。Logstash已經成爲一種解析和過濾日誌再將它們轉發到單一聚合節點的簡單方法。雖然 Logstash 也提供了一些日誌的搜索和過濾功能，但配合Graylog2使用，能提供更全面的日誌查詢和報告功能。

咱們認爲 Snowplow Analytics 在網絡數據分析方面具備遠大前景。它是一個開源網絡分析平臺，基於公開數據原則和雲存儲，並能從常規的網絡分析中得出智能信息。

咱們在 ThoughtWorks 的項目中看到對 PhantomJS 的興趣，它是一個針對現實目標進行功能測試的 headless 網絡測試工具。

Gatling 是另外一個在自動化性能測試領域的新成員。它和 Locust 相似，都比傳統的 JMeter 和 Grinder 更輕量級。Gatling 的DSL構建在Scala基礎上，提供了易配置的數據源和響應斷言等普遍的開箱即用功能。在須要個性化配置時，也能夠很容易直接使用Scala 來進行擴展。經過 Highcharts 默認生成數據的各類動態視圖的功能，更增長了它的吸引力。

許多已經遷移到敏捷工做方式的組織還在繼續使用重量級的測試工具。這些工具並不適合快速發展的軟件交付。重量級測試工具較陡的學習曲線及對專業技能和培訓的要求，使團隊很難使用這些工具來進行測試。一般這會致使隨着其餘團隊的加入，對於每個版本的發佈都形成沒必要要的開銷。這些工具昂貴的軟件受權費用更加重了這個問題。一些重量級的測試工具使用「模型驅動」的方法，試圖精確地對應用程序的使用模式進行建模，但軟件缺陷的誤報卻致使測試腳本昂貴的的開發和維護代價。其實咱們常常看到一些簡單的開源解決方案能以少得多的時間、精力和預算，給予對所要求的軟件質量的信心。

基於語言的構建工具 Gradle 和 Rake 繼續提供比Ant 和 Maven 等基於XML和插件的構建工具更細粒度的抽象和更靈活的長期解決方案。這使得它們在項目變得更加複雜時，還能保持優雅的增加。

咱們繼續看到嘗試使用 TFS 做爲版本控制系統的那些團隊遭遇到生產力降低的問題。那些團隊在實踐做爲持續集成核心部分的頻繁代碼提交時，發現TFS重量級的方式顯著下降了生產效率。這每每致使團隊更少地進行代碼提交，致使產生諸多問題的代碼合併。咱們建議使用 Git、Perforce和 Subversion。

語言和框架

隨着支持數據綁定、客戶端模板和校驗等功能的框架的蓬勃發展，單頁面Web應用開發繼續高歌猛進。在ThoughtWorks， 諸如AngularJS、Knockout和 Ember.js 這樣的 JavaScript MV* 框架有着普遍的應用，且各有其倡導者和反對者。咱們指望在此充滿活力的領域有更多的創新。

隨着基於Node.js的服務器端應用程序的持續增加，單頁面應用和基於移動瀏覽器的應用漸漸融入主流， CoffeeScript 也因其能簡化 JavaScript 代碼而愈來愈多地獲得採用。做爲一種將源代碼編譯成 JavaScript 代碼以供運行時執行的語言，CoffeeScript應用程序的調試難度備受關注。CoffeeScript 1.6.1 引入了 Source Maps 以幫助開發工具生產廠商解決這個問題，同時，像Dropbox 這樣的著名技術公司也開始使用 CoffeeScript，咱們預計它將得到更普遍的應用。

咱們在新產品中對node.js的使用越多，對可靠的 JavaScript 包管理工具的需求就越迫切。Node Package Manager（npm）做爲 node.js 應用的打包工具，是其生態系統的重要組成部分。對於要面對大量 JavaScript 或 CoffeeScript 代碼的瀏覽器應用開發人員來講，應考慮使用 Require.js 組織代碼結構以及在運行時裝載依賴。

在客戶端和服務器端，微框架正成爲解決應用程序複雜度日益增長問題的新興方式。Sinatra正是這一領域的先驅，它可以使用輕量級DSL在服務器端構建快速的、易於組合的服務。其它語言也有相似的框架，例如Java平臺下的Spark、Python語言的Flask、面向Scala的Sclatra、基於Clojure的Compojure 和 .NET平臺下的Nancy。

在.NET平臺上，構建一個多樣的、開源的Web開發生態系統始終寸步難行，緣由之一就是對IIS和ASP.NET 框架的過分依賴。OWIN之於.NET平臺，正如Rack之於Ruby 社區，它定義了一個開放的HTTP操做接口，從而將Web服務器從應用程序中解耦出來。咱們爲此激動不已，由於OWIN打開了一扇大門，使得在.NET平臺下誕生簡單的、可獨立開發模塊的Web開發工具成爲可能。Nancy 正是一個利用這種可能性的完美例子。咱們也但願它能促令人們在.NET平臺下將web應用程序部署爲單獨的、自託管服務方面進行更多的實踐。

最近發佈的Play Framework 2.1.1 支持控制器依賴注入、異步、非阻塞I/O、Code - Reload工做流、數據庫遷移、資源管道以及靈活的部署選項，這些特性對開發者產生了更大的吸引力。基於這個緣由，Play從新出如今咱們的技術雷達上，咱們但願團隊在 JVM 上構建 Web 應用程序和服務時，認真考慮選用 Play。然而須要提醒的是，Play 使用了函數式編程風格，在結合使用 Java 時， Play 會產生過多的靜態方法，所以很難在運行中的服務器外圍進行單元測試。

和 JavaScript、HTML 同樣，CSS 是構建網站的核心技術。很不幸，CSS 自己缺少一些關鍵特性，這致使代碼具備高度重複性而且缺少有意義的抽象。雖然 CSS3 旨在糾正其中的一些問題，但要等到大多數瀏覽器都正確支持 CSS3 ，恐怕還需不少年。幸運的是，經過 SASS，SCSS，LESS 這樣的 CSS 框架能夠幫助解決這個問題。基於這些框架的質量和相應支持，咱們相信，除非須要細微的樣式調整，手寫 CSS 的時代已經一去不復返了。

CSS 框架簡化了大規模 CSS 代碼的開發，而無需每次都從頭開始。面對琳琅滿目的各類框架，選擇一個支持持續加強與維護，而不只僅是可以快速上手的框架就顯得尤其重要。就這一點而言，基於 mix-ins 的框架如Compass，或者Susy這種有針對性的框架，將是更合適的選擇。

Twitter Bootstrap 是一個流行的 CSS 框架， 它能夠幫助你快速構建流暢的、具備響應式佈局（responsive layouts）的精美網站。基於咱們長期的使用經驗，在此版技術雷達中，咱們把 Bootstrap 從試用階段移到了評估階段。若是想要替換或定製應用程序外觀，其與 HTML 標記的深度集成將成爲須要面對的挑戰。但這並不妨礙你選擇Twitter Bootstrap，只是作決定時須要考慮到這些限制。

---

感謝張凱峯對本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工做，請郵件至editors@cn.infoq.com。也歡迎你們經過新 浪微博（@InfoQ）或者騰訊微博（@InfoQ）關注我 們，並與咱們的編輯和其餘讀者朋友交流。