ThoughtWorks編輯｜小智ThoughtWorks 已於昨日釋出了最新一期的技術雷達，InfoQ 第一時間拿到了先手資料，提取了朋友們最感興趣的內容整理成文，以饗廣大讀者。本文將從技術、平臺、工具、語言&框架等四個方面，為你詳解技術未來的趨勢。寫在前面

ThoughtWorks 中一群資深技術領導組成的ThoughtWorks 技術顧問委員會 （TAB） 建立了該雷達。 他們定期開會討論 ThoughtWorks 的全球技術戰略以及對行業有重大影響的技術趨勢。這個雷達以獨特的形式記錄技術顧問委員會的討論結果，為從開發人員到 CIO 在內的各路利益相關方提供價值。 這些內容只是簡要的總結， 我們建議您探究這些技術以瞭解更多細節。

這個雷達是圖形性質的， 把各種技術專案歸類為技術、 工具、 平臺和語言及框架。 如果某個條目可以出現在多個象限， 我們選擇看起來最合適的象限。 我們還進一步將這些技術分為四個環以反映我們目前對其的態度。要了解關於雷達的更多背景， 請參見 thoughtworks.com/radar/#/faq

注：公眾號對話方塊回覆關鍵詞：「雷達」，下載完整版技術雷達！

這期技術雷達亮點會話式使用者介面和自然語言處理

人機對話——這種新的應用程式互動方式——伴隨著蘋果Siri 、 微軟小娜和谷歌 Allo 這樣的工具， 像風暴一樣席捲了整個IT生態圈。 隨後這股風暴繼續延伸到了家用裝置， 例如亞馬遜的 Echo 和谷歌的 Home 。 雖然構建會話式自然語言使用者介面會遇到許多新的挑戰， 但是它所帶來的益處是很顯著的。 亞馬遜 Echo 的研發團隊故意在該產品上省去了螢幕， 從而迫使團隊成員重新思考許多人機互動的場景。

這種 “會話式” 的趨勢不僅限於語音。 隨著訊息應用已經增長到可以主導電話通話和工作場所， 我們看到了一些在智慧聊天機器人協助下所發生的多人會話。 隨著這些平臺的不斷改進， 它們將逐漸學會理解會話的上下文和會話意圖，從而讓人機互動更加逼真和引人入勝。市場和主流媒體對這個領域的興趣激增， 增加了開發者對這種新的個人 “外部皮層” （exocortex） 互動模式的興趣。

智慧即服務

最近， 一系列被我們稱之為 “智慧即服務” （intelligence asa service） 的平臺已經爆發。 這些平臺都與各種強大的技術領域密切相關， 從語音處理到自然語言識別、 影象識別和深度學習。

幾年前， 要想具備這些能力還需要花費很昂貴的資源， 但現在已經有開源或者基於 SaaS 平臺的解決方案了。 這也意味著 “雲端計算之戰” 逐漸從儲存和計算能力向認知能力轉變。

之前 Kubernetes 和 Mesos 這兩個差異化工具的開源就是這場戰爭的見證。在這個領域的所有大型廠商都有自己的產品， 與此同時， 一些利基廠商的產品也值得嘗試。 儘管我們對於這些服務在倫理和隱私方面的影響持保留態度， 但我們相信創新地使用這些強大工具會帶來很好的前景。 我們的客戶已經開始在新的視野上研究如何在他們的業務裡把人工智慧和商品的認知能力結合起來。

開發者體驗成為新的差異化競爭優勢

多年來， 使用者體驗設計一直是技術產品公司持續關注的關鍵差異化競爭優勢。 而現在面向開發者的工具和產品的快速崛起， 加之工程人才的稀缺， 迫使這些公司也開始關注開發者體驗。

越來越多的組織依據所減少的 “工程摩擦力” （engineeringfriction） 來評估雲產品， 並將 API 視為產品來精心打磨， 且專注於工程生產力來提升團隊效率。 在 ThoughtWorks ， 我們一直執著於高效的工程實踐， 以及那些能讓開發者們輕鬆工作的工具和平臺。 我們非常激動地看到業界開始採納這些想法。

這些關鍵技術包括： 將內部基礎設施作為一種產品， 令其具有足夠的吸引力來與外部產品進行競爭； 專注於自助服務系統； 理解所開發的 API 的 “開發者人機工程學”（developer ergonomics） ； 對遺留系統進行封裝； 以及對開發者的 “持續使用者共情研究” （ongoing empathetic user research） 的投入。

平臺的崛起

技術雷達的主題來自於審查過程中的觀察和交流。 在最近一次編輯技術雷達的過程中， 我們注意到了進入平臺象限的新條目的數量。 我們認為這表明了平臺在軟體開發生態系統中有著更廣闊的前景。

那些引人注目的矽谷公司向我們展示了構建一個合理的平臺如何帶來顯著的效益。 他們成功的一部分原因來自於找到適用於自身的封裝和能力水平。 從技術雷達所強調的高階功能 （如自然語言處理） 到基礎設施平臺 （如亞馬遜） 來看， 越來越多的 “平臺思維” 出現在整個技術生態系統中。

當要通過產品化的 API 提供一些精選的功能時， 企業開始考慮採用平臺的方式。 開發團隊在整合和提升開發人員體驗方面有了更多的思考。 似乎業界終於走上了將 “打包、 便利和有用” 進行合理組合這樣一條道路。

我們喜歡這樣來定義平臺： 平臺應該提供一個自助服務 API， 並且使之在團隊環境中容易配置和建立——這很好地與 “開發者體驗” 這樣一個新興的主題相呼應。 我們期望在不久的將來， 平臺的定義和功能將得到進一步的完善。

盛行的PYTHON

Python 這門語言總是不斷出現在有趣的地方。 作為一門易用的通用程式語言， Python 在數學和科學程式設計領域具有堅實的基礎。 這使得它一直以來都為草根階層的學術研究社群所採用。 最近， 圍繞人工智慧商品化及其應用的行業趨勢， 以及 Python 3 的成熟， 給 Python 社群注入了新的活力。

這一卷的雷達重點介紹了一些能夠促進 Python 人工智慧生態圈發展的庫， 其中包括機器學習領域的 Scikit-learn ，採用智慧資料流圖的 TensorFlow 、 Keras 和 Airflow ， 以及通過自然語言處理實現會話識別應用程式介面的 spaCy 。我們越來越多地看到 Python 正在縮小組織內科學家和工程師之間的距離， 並減弱了他們過去在最喜愛工具方面的偏見。

諸如微服務和容器的架構已經簡化了 Python 在生產環境中的執行。 工程師現在可以通過與語言和技術無關的 API ，部署和整合由科學家們特別建立的 Python 程式碼。 相比將特定語言 （比如 R 語言） 翻譯到生產環境上的現有做法， 這種流動性是朝構建研究人員和工程師之間一致的生態系統邁出的重要的一步。

一、技術將 API 當做產品

企業已經全然接受通過 API 把業務能力暴露給內外部開發者。 API 通過重組核心能力承諾了快速試驗商業創意的能力。 但 API 與普通企業整合服務有什麼區別呢？ 其中的一個區別就是將 API 當做產品 （APIs as a product） ， 即使 API消費者是企業內部的系統或開發人員。 構建 API 的團隊應該理解客戶的訴求， 並且讓產品始終能夠滿足這些訴求。 可用性測試 (Uasbility Tesing) 和使用者體驗研究有助於理解API的使用模式， 並將產品思維帶入到 API 中， 從而得到更好的 API 設計。 API 應該有一個負責任， 負責關注使用者並持續改進。 在我們的經驗中， 缺乏產品導向會使普通企業整合和基於 API 平臺構建的敏捷業務存在差異。

從程式碼中解耦祕密資訊的管理

在往期的技術雷達裡我們提到了諸如 git-crypt 和Blackbox 這樣的工具可以幫我們保證原始碼內部的祕密資訊保安。 從程式碼中解耦祕密資訊的管理是我們提醒技術人員儲存祕密資訊還有其他選項的另一種方式。 例如，HashiCorp vault 持續整合伺服器和配置管理工具都提供了脫離應用程式程式碼的祕密資訊儲存機制。 這兩種方法都切實可行， 我們推薦你在專案中至少使用一種。

構建 API 的團隊應該理解客戶的訴求， 並且讓產品始終能夠滿足這些訴求。 可用性測試(Uasbility Tesing) 和使用者體驗研究有助於理解API的使用模式， 並將產品思維帶入到 API中，從而得到更好的 API 設計。— APIs as a product

封裝遺留系統

在遺留程式碼上工作， 特別是大型的單體應用， 是最糟糕的開發體驗之一。 儘管我們警告不要擴充套件和積極維護遺留單體應用， 但它們仍然是各種環境中的依賴。 開發人員往往低估了這些依賴開發所需的成本和時間。 為了減少摩擦， 開發人員採用虛擬機器映象或 Docker 容器來建立遺留系統及其配置的映象。 其目的是為了封裝遺留系統並供開發人員在本地執行。 從而消除重新構建、 重新配置和共享環境時候對遺留系統的需要。

在理想情況下， 團隊通過流水線生成相應的遺留系統映象。 開發人員可以通過更可靠的方式在自己的沙盒環境中編排並執行這些遺留系統。 雖然這種方法可以減少每個開發人員花費的總時間， 但是當擁有下游依賴的團隊不願意建立遺留系統映象供他人使用時， 這種方法的成效會很有限。

漸進式 Web 應用

漸進式 Web 應用 (PROGRESSIVE WEB PPLICATIONS)(PWAs)的增長是把使用者帶回 Mobile Web 以迴應 “移動應用疲勞” 的最新一次嘗試。 它最初由 Google 在2015年提出， PWA 是利用了最新技術的優勢來組合出最好的 Web和原生移動應用程式的 Web 應用程式。 它使用了一系列的開放標準技術， 比如 service workers , app manifest 以及快取和推送API 。 我們可以通過這些技術創建出與平臺無關的移動應用以及原生應用的使用者體驗。 這平衡了 Web 應用和原生應用各自的優缺點， 並幫助移動應用開發者打破了應用商店的限制去接觸使用者。 你可以把 PWA 想作是具備原生應用功能和觀感的 Web 站點。

無伺服器架構

無伺服器架構這種方法通過短暫存在的計算能力來替代長期執行的虛擬機器。 這種計算能力會根據服務請求而存在， 並在服務完成後立即消失。 我們的團隊非常喜歡無服務架構這種方法。 這種方法工作良好， 我們認為它是一種有效的架構選擇。 值得注意的是這種方法並不是一種 “要麼全部採用，要麼全部不用” 的方法。 我們的一些團隊已經使用無伺服器架構來部署新的系統模組， 而對於其他模組則仍然使用傳統的架構。 雖然 AWS Lambda 幾乎是 無伺服器的代名詞，但是其他的雲端計算服務商都提供了相似的產品。 我們也建議評估一些利基玩家， 例如 webtask 。

會話感知 API

諸如 Amazon Alexa ， Google 語音服務和Siri 這樣的技術已經大大降低了基於語音的軟體互動的門檻。 然而， 想要在許多現有的API 之上構建更多的會話式輸入 （語音或文字） 還很困難。— Conversationally aware APIs

諸如 Amazon Alexa ， Google 語音服務和 Siri 這樣的技術已經大大降低了基於語音的軟體互動的門檻。 然而， 想要在許多現有的 API 之上構建更多的會話式輸入 （語音或文字）還很困難。 特別是在涉及到有狀態的互動場景， 且後續的互動又需要知曉整個會話上下文時。 在這種風格的互動中， 如果我們想要詢問從曼徹斯特到格拉斯哥的火車， 就可以直接問 “首班列車何時出發？ ” ， 而不必再次給出會話的上下文。

通常這個上下文將出現在我們傳送回瀏覽器的初始響應中。 但在語音介面的情形下， 我們需要在其他地方處理這個上下文。 會話感知 API 是後端為前端服務模式的示例， 其中前端是語音聊天平臺。 這種型別的 API 可以在代表語音前端呼叫底層服務時， 通過管理會話的狀態來處理這種互動方式的細節。

遊戲領域之外的 VR 應用

虛擬現實的想法已經存在了50多年了， 隨著計算技術的不斷進步， 許多想法都已被炒作和探索過。 我們相信該領域目前已經達到了臨界點。 去年， 市場上已經發布了價格適宜的、 面向消費者的 VR 頭戴式裝置， 再加上現代的圖形顯示卡為這些裝置提供了足夠的效能以創造身臨其境的體驗。 雖然這些頭戴式裝置目前主要還是針對視訊遊戲愛好者， 但我們相信， 它們在遊戲領域之外的 VR 應用上還存在許多的可能性。 但是， 沒有製作視訊遊戲經驗的團隊不應低估建立一個好的3D模型和紋理所需要的時間和技能。

二、平臺LINUX 安全模組

“最小許可權原則” 鼓勵我們限制軟體只訪問他們需要的資源。 然而在通常情況下， Linux程序可以執行其執行的使用者可以做的任何操作， 包括繫結埠和執行指令碼。 LINUX 安全模組 （LSM） 框架允許將安全性擴充套件至核心， 例如 Linux 使用該模組來實現 MAC 。 SELinux 和 AppArmor 是最著名的 LSM 相容實現， 它們隨 Linux 核心一起釋出。 我們建議團隊學習使用這些安全框架 （這就是為什麼我們將其放置在採用） ， 它可以幫助團隊評估誰可以訪問共享主機上的哪些資源 （包括其中的服務） 。 這種保守的訪問管理方法將幫助團隊在其SDLC流程中建立更好的安全性。

AMAZON API GATEWAY

AMAZON API GATEWAY 允許開發者把 API 服務暴露給網際網路的使用者。 它提供了 API 閘道器的常見功能： 流量管理，監控， 認證和授權。 我們的團隊在把它和 AWS Lambda 整合作為無伺服器架構的一部分上有很積極的評價。 另一方面， 我們在把它用作一個執行在 EC2 上的 HTTP/HTTPS 端點之前的更通用的前置閘道器時遇到了更多挑戰， 對我們造成了阻礙的是 VPC 的缺乏互動性和在閘道器上建立客戶端證書驗證的困難。 基於這種混合的使用體驗， 我們建議團隊結合使用 AWS API Gateway 和 Lambda 。 但在更通用的配置裡使用它時要評估其適用性。

OPENTRACING

隨著單體應用被更復雜的 （微） 服務生態系統所取代， 跨越多個服務的請求追蹤正成為常態。 幸運的是OPENTRACING 正在迅速成為分散式追蹤的事實上的標準。 它由Uber， 蘋果， Yelp和各種其他大廠商開發， 它支援多種分散式追蹤系統， 如 Zipkin ， Instana 和 Jaeger 。OpenTracing 標準目前提供廠商中立的六種語言實現： Go， JavaScript ， Java ， Python ， Objective-C ， 以及 C++ 。

MESOSPHERE DCOS

MESOSPHERE DCOS 是一個基於 Mesos 構建的平臺。它將底層基礎設施抽象出來， 適用於容器化的以及沒有執行在 Docker 內的應用程式。 這可能對更多 “適量部署”（modest deployments） 而言是過度的， 但是我們開始看到它在商業版本和開源版本中的成功。 我們尤其喜歡它在不同的雲端計算供應商和專用硬體之間的可移植性， 因此可以使你擺脫對於單一容器編排框架的依賴。 雖然升級可能會比我們想要的更復雜一點， 但整個技術棧正在變得更加穩定。

Tango

由於對硬體的要求和構造虛擬世界的複雜度門檻較高， 除了虛擬現實 （VR） 之外， 替代現實 （AR） 和混合現實 （MR） 也在去年進入主流。 Pokémon Go 的風靡則證明了： 普通的智慧手機也足以創造引人矚目的 AR/MR 體驗。 TANGO 是一種用於手機的新型硬體感測器技術， 進一步增強了在手機上實現 AR / MR 的可能性。 它允許應用程式獲取使用者周圍的詳細的 3D 測量資料， 以便在攝像頭輸入流中放置和呈現更有說服力的虛擬物件。 第一批使用 Tango 技術的手機現已上市。

語音平臺

諸如 Amazon Alexa 和 Google Home 這樣的語音平臺目前處在技術界的風口浪尖 技術成熟度曲線 （hype cycle） 的炒作頂峰， 甚至有人預言， 未來會話式的語音介面會無處不在。 我們已經有把對話式UI整合到產品中的經驗， 並且看到了這種新的互動方式對介面設計的影響。 Alexa 則全部從頭設計， 他們捨棄了螢幕並將會話式使用者介面視為一等公民。 但現在要相信這樣的炒作還為時過早， 我們期待更多的大廠商進入這個領域。

WEBVR

WEBVR 是一組可讓你通過瀏覽器訪問 VR 裝置的實驗性JavaScript API 。 它已經獲得了技術社群的支援， 並有正式版本和每日構建的版本可用。 如果你想在瀏覽器中構造VR 體驗， 那麼 WebVR 將會是一個不錯的開始。 此項技術以及相關補充工具， 例如 Three.js ， A-Frame ， ReactVR ，Argon.js 和 Awe.js 都能夠為瀏覽器帶來 AR 體驗。 除了網際網路委員會標準以外， 該領域中的各種工具也將有助於促進 AR 和 VR 更廣泛的應用。

三、工具FASTLANE

Web 應用程式開發者在簡化和自動化各種應用程式的工作流程時很容易， 他們可以從各種成熟的解決方案中選擇最合適的方案來自動化釋出流程。 但是， 當在開發移動應用程式時， 我們需要處理兩個不同的作業系統， 處理兩種完全不同的構建， 測試， 分發， 生成螢幕截圖， 簽名和釋出應用程式的方式。 為了解決這個痛點， 我們的團隊採用了FASTLANE 作為自動化 iOS 和 Android 應用的釋出流程的工具。 通過一些簡單的配置和多個釋出流水線， 他們就實現了移動開發的持續交付。

AIRFLOW

AIRFLOW 是一個用來通過程式設計建立、 排程和監控資料流水線的工具。 通過將有向無環圖 （DAG） 以程式碼形式表現， 它主張可維護、 可版本化並且可測試的資料流水線。 我們在專案中利用這一配置來建立動態流水線， 使得資料工作流更加高效和清晰。 Airflow 可以很容易的定義你自己的操作符和執行器來擴充套件庫， 以適配符合你的環境的抽象層次。

CAKE 和 FAKE

MSBuild 自從2005年推出以來一直是 .NET生態系統中的主要構建系統。 但是， 它遇到了我們以前在 Maven 中提到的許多相同的問題。 .NET社群已經開始開發MSBuild的替代品， 它更容易維護且更加靈活， 並能隨著專案的增長更自然的演化。 CAKE 和 FAKE 是其中的兩個備選方案。 Cake使用一種 C# 內建的 DSL， 而 Fake 使用 F# 。 在過去的一年裡這兩個專案都取得了顯著的增長， 足以證明在 .NET 專案中它們是替代 MSBuild 編排常見構建任務的可行方案。

SERVERLESS FRAMEWORK

非常流行的 SERVERLESS FRAMEWORK 為無伺服器風格架構的應用程式提供了專案腳手架和部署工具。 它的大部分使用場景都是基於 AWS Lambda 以及相關 AWS 產品。 Serverless Framework 為 JavaScript, Python, Java 和C# 語言提供了專案模板， 並擁有有一個活躍的社群為其貢獻擴充套件外掛。 此外， 它也向作為 AWS Lambda 替代品的Apache 孵化器專案 OpenWhisk 提供支援。

MOLECULE

MOLECULE 旨在幫助開發和測試 Ansible 的 Role 。 通過在虛擬機器或容器上為正在執行的 Ansible Role 的測試構建腳手架， 我們無需再手工建立這些測試環境。 Molecule利用 Vagrant ， Docker 和 OpenStack 來管理虛擬機器或容器， 並支援 Serverspec 、 Testinfra 或 Goss 來執行測試。 在sequence facility model中的預設步驟包括： 虛擬機器管理，Ansible 語法靜態檢查， 冪等性測試和收斂性測試。 雖然這是一個相當年輕的專案， 但我們看到了其蘊含的巨大潛力。

SPINNAKER

Netflix 把旗下的 Spinnaker 開源了。 它是一個微服務的持續交付平臺。 相比其他的 CI/CD 平臺， SPINNAKER 將叢集管理和烘培映象部署當作頭等功能來實現。 它支援開箱即用的部署和多種雲平臺 （例如 Google Cloud Platform，AWS和 Pivotal Cloud Foundry ） 的叢集管理功能。 可以把Spinnaker 整合到 Jenkins 裡來執行構建任務。 我們喜歡Spinnaker 在雲端部署微服務的率性做法， 可惜它的流水線只能通過使用者介面而不是程式碼來建立。

YARN

YARN 是一個新的包管理工具， 它可替換現有 npm 客戶端的機制， 同時相容 npm 登錄檔。 如果使用 npm 客戶端， 根據依賴庫的不同安裝順序， 它會在 node_modules下得到一個不同的樹結構。 這種非確定性的特點可能導致 “在我的機器上能工作” 的問題。 通過將安裝步驟分解為解析、 獲取和連結， Yarn 使用確定性演算法和 lockfiles避免了這些問題， 從而確保重複安裝的一致性。 因為它對已經下載的包進行快取， 我們還看到在持續整合 （CI） 環境中的構建速度明顯更快。

四、語言&框架Python 3

PYTHON 3 引入了很多有用的特性， 這些特性和 Python2.x 不相容。 它還移除了大量 Python 2.x 中用於向後相容的功能， 這讓 Python 3 更容易學習和使用， 而且和語言的其他部分更加一致。 根據我們在機器學習和 web 應用開發這樣的領域中使用 Python 3 的經驗顯示， 語言本身以及大多數支援庫都已經成熟到可被採用的程度。 我們可以 fork 已有的庫併為其存在的小問題打補丁， 或者避免使用已經被放棄的不相容的 Python 2.x 庫。 如果你在使用 Python 做開發， 我們強烈鼓勵你使用 Python 3。

REACTIVEX

分散式系統經常利用多執行緒、 基於事件的通訊和非阻塞 I/O來提高整體系統效率。 這些程式設計技術提出了諸如低階執行緒、同步、 執行緒安全、 併發資料結構和非阻塞 I/O 等挑戰。 開源的 REACTIVEX 庫優雅地解決了這些問題， 提供了所需的應用程式管道， 並擴充套件了非同步事件流之上的觀察者模式。ReactiveX 還擁有一個活躍的開發者社群， 支援的程式語言越來越多， 最近支援的是 RxSwift 。 它還實現了繫結到移動和桌面平臺的功能。

AVRO

AVRO 是一個數據序列化的框架。 它通過將 schema 與訊息內容共同存放的方式來鼓勵 schema 演進。 生產者可以編輯欄位名稱， 新增新欄位或刪除現有欄位， 而 Avro 確保客戶端可以繼續消費訊息。 Schema 允許每個資料被寫入而沒有額外開銷， 促成了緊湊的資料編碼和更快的資料處理。 儘管生產者和消費者之間無結構訊息的交換形式可以很靈活， 但我們已經看到團隊在部署期間遇到佇列中出現無法處理的不相容訊息的問題。 我們在許多專案中使用了Avro ， 並且建議僅在傳送非結構化訊息時使用它。

VUE.JS

在日新月異的前端 JavaScript 框架世界裡， VUE.JS 作為AngularJS 的輕量級替代品佔據了一席之地。 它是一個非常靈活——且沒有預設主張——的庫。 它圍繞著模組化、 元件和響應式資料流等概念， 為構建互動式 Web 介面提供了一套工具集。 它的學習門檻很低， 這讓初級開發者和新手很感興趣。 Vue.js 本身並不是一套大而全的框架。 它僅專注在檢視層， 因而可以輕鬆地和其他庫或現有專案做整合。

CAFFE

CAFFE 是一個用於深度學習的開源庫， 由伯克利視覺和學習中心開發。 它主要專注於計算機視覺應用的卷積網路。 對於計算機視覺相關的任務， Caffe 是一個可靠並且流行的選擇， 而且可以從 Caffe Model Zoo 下載很多Caffe使用者建立的開箱即用的成功模型。 與 Keras 一樣，Caffe也是一個基於 Python 的 API 。 它們的不同之處在於， Keras 中的模型和元件是在 Python 程式碼中直接被建立的物件， 而 Caffe的模型是用 Protobuf 配置檔案描述的。 這兩種方式各有其優缺點， 並且可以相互轉換。

POSTCSS 是一個基於 Node.js 的 JavaScript 框架， 它有繁榮的外掛生態圈， 能夠操作基於抽象語法樹的 CSS 檔案。 PostCSS 常常被誤認為是一種前處理器 （如 SaaS 或者 Less ） ， 然而我們發現， 它的實力來源於其豐富多樣的外掛所提供的功能， 包括語法檢查 stylelint 外掛、 交叉編譯sugarss 外掛） 、 命名改編以避免選擇器衝突 （ modules 外掛 ） 、 模板 CSS 程式碼生成 （ autoprefixer 外掛 ） 、 檔案壓縮等等。 儘管外掛的成熟度各不相同， PostCSS 本身仍然是一個簡潔而強大的前端開發框架， 它能夠像對待一個完整前端開發語言一樣處理 CSS 。

歡迎關注技術公眾號：架構師成長營