《技術雷達》是一份技術趨勢快照，來自我們最近在軟體行業的最新發現。

以下是本期的一些重點內容：

為爭霸主，雲產品還未成熟就已入市

之前我寫過一篇文章，其中提到雲已成為當今業界的主導基礎設施和架構模式，而且各大雲供應商都在爭奪市場份額，爭取搶佔先機。在我看來，這就導致他們在一些功能和服務遠為真正成熟之前，就急於將產品推向市場。在過去，我們經常看到這種模式，企業軟體供應商會宣稱自己的產品擁有比競爭對手更多的功能，而不管這些功能在產品中是否已經完善或可用。這個問題本身並不是什麼新問題，但卻是當今雲服務行業面臨的一大挑戰。這也不是意外，而是一種有意的戰略，是雲公司為了快速推出軟體而對自身進行重組所產生的結果。

各個雲平臺競相推出新的產品和服務，這不一定會給使用這些平臺的團隊帶來好處。供應商過度承諾，言過其實，因此團隊作為買方需要保持謹慎。當有新的雲資料庫或其他服務問世時，團隊必須要評估這些服務是否真正成熟，可供他們使用。團隊能否承受這些服務不可避免尚需完善的缺陷和侷限性？

混合雲工具開始日趨成熟

許多大型組織都處於“混合雲”狀態，使用不止一個雲提供商。是應該採用一個還是多個雲服務提供商？這個選擇非常複雜，不僅要考慮技術，還要考慮商業、政治甚至監管因素。例如，在監管非常嚴苛的行業，組織可能需要向監管機構證明，如果他們的現有云提供商遇到某種災難性的技術或商業問題，使他們無法持續運營，他們可以很輕鬆地轉向新的雲提供商。我們的一些客戶正在進行重大的雲整合工作以過渡到單一雲平臺，因為多雲存在延遲、VPN 設定複雜的問題，也有的組織進行整合是為了從供應商處獲得更優惠的定價，或者獲得特定的雲功能（例如支援 Kubernetes 或使用特定機器學習演算法）。

這種過渡或整合可能需要數年時間，尤其是考慮到遺留企業系統對此類計劃的影響，因此組織需要一種更好的方法來處理多雲。一些“混合雲控制平面”正在興起，有助於減輕這種痛苦。我們認為，如果你正在遭受多雲的困擾，可以考慮使用 Google Anthos、AWS Outposts、Azure Arc 和 Azure Stack。

“量子就緒型”雲或將成為明年的關鍵戰略

Google 最近正在宣揚他們在所謂“量子霸權”方面取得的成就，他們開發了一臺量子計算機，可以執行傳統計算機基本上無法應對的演算法。具體情況是，Google 使用了一臺 53 量子位的量子計算機在 200 秒內解決了一個傳統超級計算機需要一萬年才能解決的問題（IBM 駁斥了谷歌的說法，認為自己的超級計算機可以在 2.5 天內獲得這樣的結果）。這裡要指出的重點是，量子計算機不僅僅是實驗室裡的昂貴裝置，它已經跨越各種潛在障礙，能夠通過量子計算解決更大規模的重要問題。

目前，使用少數量子位可以解決的問題在數量和實用性方面都很有限，但是量子計算無疑擁有廣闊前景。加拿大初創公司 Xanadu 不僅在開發量子晶片（Google 使用的是超導體，而 Xanadu 是使用“光子”方法來捕獲量子效應），而且還在開發量子模擬和訓練工具。他們指出，儘管目前的大多數量子演算法看起來有點理論化，但是可以使用量子技術來加速解決蒙特卡洛模擬之類的問題，這在當今金融科技等領域非常有用。

像對待許多技術轉型（大資料、區塊鏈、機器學習）一樣，你至少要基本熟悉這項技術並了解它可以為你的企業帶來什麼好處。IBM、Microsoft 和 Google 都提供量子計算機模擬工具，在有些情況下還可提供真正的量子計算硬體獲取途徑。雖然你們的企業可能目前還不能受益於高度專用的演算法加速技術，但是“量子就緒型開發者”雲很快就會像過去“資料科學家”那樣流行起來。

當我們聲稱要扼殺過時系統時，問題就來了，因為最終我們只能在這些過時系統的基礎上構建額外的系統和 API，而從未真正淘汰掉那些過時的系統。我們的同事 Jonny LeRoy（他善於給事物取名字）稱這種方法對於過時系統而言只是“隔靴搔癢”，建議我們將它放在技術雷達評估的“Hold”（暫緩）環節。我們原本認為這個技術太複雜，但是人們都很喜歡聽到這樣的訊息：如果我們計劃使用扼殺者模式來淘汰過時系統，我們最好著手進行淘汰，否則我們的努力往往都會白費。

主幹開發似乎正在失去戰鬥力

多年來，我們一直在推廣主幹開發，認為最好的軟體開發方法就是讓每個開發者直接將他們的程式碼提交到原始碼管理的“主線”（每天如是，越多越好）。就像有些見過很多原始碼混亂情況的人一樣，我可以肯定，分支模型並非免費（甚至談不上便宜），即使是結合 Git 等工具編寫的工整程式碼也無法使團隊避免這種“持續隔離”的開發模式導致的各種問題。人們為需要採用分支程式碼給出的原因往往正好表明團隊或系統架構存在深層次問題，需要直接予以解決，而不是採用程式碼分支。例如，如果你不信任某些開發人員向你的專案提交的程式碼，於是使用分支或 Pull Request 作為程式碼稽核機制，那麼實際上你應該解決的是核心信任問題。如果你不確定能否趕上專案截止日期，於是想用分支來為候選版本“cherry pick”最佳變更內容，你就會陷入痛苦之中，那麼實際上你應該解決專案預估、優先事項安排和專案管理問題，而不是用分支來敷衍這個問題。

遺憾的是，我們在這方面似乎無法挽回局勢。GitFlow 等短期分支技術繼續受到歡迎，使用 Pull Request 來管理程式碼審查等活動也同樣廣受青睞。我們以前的同事 Paul Hammant 建立了 trunkbaseddevelopment.com 並且一直在進行維護，他也建議採用短期功能分支來執行大規模的主幹開發。雖然我們最喜歡的這項技術似乎正在失去戰鬥力，這讓我們很難過，但我們仍然希望志同道合的團隊將繼續儘可能地推動明智的主幹開發。

翹首期待 Apple 釋出 XR

在最近的 Facebook Connect 大會上，Oculus 確認他們正在開發 AR 眼鏡，但未釋出任何具體細節。最新傳言稱，Apple 將於 2020 年釋出某種 XR 耳機，並且將於 2022 年釋出 AR 眼鏡。就像在智慧手機和智慧手錶等許多其他先進技術領域一樣，在打造真正吸引使用者的體驗設計方面，Apple 很可能再次走在前沿。Apple 的魅力始終在於將先進技術與卓越的消費者體驗結合起來，只有在真正做到這一點之後，他們才會進入市場。很長一段時間以來（也許今天仍然如是），Apple 的人機介面設計準則一直是應用開發者必讀的經典。我預計，Apple（最終）進入 AR 領域時，也會實現類似的飛躍。在此之前，雖然會出現一些精巧的演示和有限的訓練體驗，但 XR 仍將是一種小眾技術。

機器學習繼續製造驚喜，但是我們真正理解它嗎？

我最喜歡的一個 YouTube 頻道是 Two Minute Papers（兩分鐘論文），在其中研究員 Károly Zsolnai-Fehér 會對 AI 系統的發展進行報道，令人眼界大開。最近，該頻道介紹了一系列 AI 技術，有的可以基於僅僅五秒鐘的輸入模擬人類語音；有的可以推導客觀世界的運動規律，速度是傳統物理模擬系統的三萬倍；有的可以學習如何玩捉迷藏，並且從真正意義上打破相應遊戲世界的規則。這個頻道做得很出色，展示了狹義 AI 能力的驚人（甚至有點可怕）的進步，通常用於解決可以直觀顯示的問題，因此是良好的視訊展示內容。但是機器學習也被應用到許多其他領域，比如商業決策、醫療，甚至用於為法官給罪犯量刑提供建議，所以我們必須了解人工智慧或機器學習系統如何運作。

一個大問題是，儘管我們可以描述一個基礎演算法如何執行（例如神經網路的反向傳播如何工作），但是我們無法解釋網路在經過訓練之後實際上會怎麼執行。本期《技術雷達》將介紹 what-if 等工具和道德偏見測試等方法。我們認為，在選擇機器學習模型時，可解釋性是應當考慮的一個重要因素。

Mechanical Sympathy（機械同感）再度迴歸

早在 2012 年，《技術雷達》介紹了一個概念“Mechanical Sympathy”（機械同感），當時是基於 LMAX Disruptor 團隊的工作闡述了這個概念。那時候，許多軟體應用編寫的抽象化程度越來越高，Disruptor 越來越接近 metal 的水平，專為在特定 Intel CPU 上實現極高效能進行了調優。LMAX 問題在於它本質上是單執行緒的，需要單 CPU 機器提供極高效能。看來，似乎 Mechanical Sympathy（機械同感）問題又迴歸了。

上一期《技術雷達》介紹了 Humio，這是一種日誌聚合工具，在日誌聚合和查詢方面速度都超快。這一期《技術雷達》將介紹 GraalVM，一款高效能虛擬機器。我們認為具有諷刺意味的是：軟體行業的許多先進技術都是脫離了硬體（容器、Kubernetes、功能即服務、雲資料庫等等），而有一些技術仍然高度關注我們用於執行這些技術的硬體。我認為這要取決於使用案例。你需要可擴充套件性和彈性嗎？那就離開硬體，進入雲端。但是對於高頻交易等非常具體的使用案例，該怎麼辦？那還是要利用上述某些技術，更專注於從硬體上實現進步。

希望你喜歡我們對技術行業最新趨勢的這些簡要介紹。由於版面空間限制，有些其他內容沒做介紹，可以在技術雷達（https://www.thoughtworks.com/cn/radar）中閱讀相關內容。