search
尋找貓咪~QQ 地點 桃園市桃園區 Taoyuan , Taoyuan

從技術、平台、工具、語言&框架等四大方面,詳解技術未來的趨勢

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

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

這個雷達是圖形性質的, 把各種技術項目歸類為技術、 工具、 平台和語言及框架。 如果某個條目可以出現在多個象限, 我們選擇看起來最合適的象限。 我們還進一步將這些技術分為四個環以反映我們目前對其的態度。

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

人機對話——這種新的應用程序交互方式——伴隨著蘋果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 。

從VS 2017談起,解析微軟技術生態進化之道



熱門推薦

本文由 yidianzixun 提供 原文連結

寵物協尋 相信 終究能找到回家的路
寫了7763篇文章,獲得2次喜歡
留言回覆
回覆
精彩推薦