ThoughtWorks：技術雷達-有態度的前沿技術解析（第27期）（39頁）.pdf

《ThoughtWorks：技術雷達-有態度的前沿技術解析（第27期）（39頁）.pdf》由會員分享，可在線閱讀，更多相關《ThoughtWorks：技術雷達-有態度的前沿技術解析（第27期）（39頁）.pdf（39頁珍藏版）》請在三個皮匠報告上搜索。

1、有態度的前沿技術解析第 27 期技術雷達Thoughtworks 技術雷達 Thoughtworks,Inc.All Rights Reserved.關于技術雷達3雷達一覽4貢獻者5本期主題6TheRadar8技術11平臺19工具26語言和框架33 Thoughtworks,Inc.All Rights Reserved.Thoughtworks 技術雷達關于技術雷達Thoughtworker 酷愛技術。我們為每個人建造技術，研究技術，測試技術，開源技術，書寫技術，并不斷致力于改進技術。我們的使命是支持卓越軟件并掀起 IT 革命。我們創建并分享Thoughtworks 技術雷達就是為了支持這一

2、使命。由 Thoughtworks 中一群資深技術領導組成的 Thoughtworks 技術顧問委員會創建了該雷達。他們定期開會討論 Thoughtworks 的全球技術戰略以及對行業有重大影響的技術趨勢。技術雷達以獨特的形式記錄技術顧問委員會的討論結果，從首席技術官到開發人員，雷達為各路利益相關方提供價值。這些內容只是簡要的總結。我們建議您探究這些技術以了解更多細節。技術雷達的本質是圖形性質，把各種技術項目歸類為技術、工具、平臺和語言和框架。如果技術可以被歸類到多個象限，我們選擇看起來最合適的一個。我們還進一步將這些技術分為四個環以反映我們目前對其的態度。Thoughtworks,Inc.A

3、ll Rights Reserved.雷達一覽技術雷達持續追蹤有趣的技術是如何發展的，我們將其稱之為條目。在技術雷達中，我們使用象限和環對其進行分類，不同象限代表不同種類的技術，而環則代表我們對它作出的成熟度評估。軟件領域瞬息萬變，我們追蹤的技術條目也如此，因此您會發現它們在雷達中的位置也會改變。技術雷達是具有前瞻性的。為了給新的技術條目騰出空間，我們挪出了近期沒有發生太多變化的技術條目，但略去某項技術并不表示我們不再關心它。暫緩評估試驗采納采納：我們強烈主張業界采用這些技術。我們會在適當時候將其用于我們的項目。試驗：值得追求。重要的是理解如何建立這種能力。企業應該在風險可控的項目中嘗試此技術

4、。評估：為了確認它將如何影響你所在的企業，值得作一番探究。暫緩：謹慎推行新的挪進/挪出沒有變化4 Thoughtworks,Inc.All Rights Reserved.貢獻者技術顧問委員會（TAB）由 Thoughtworks 的 17 名高級技術專家組成。TAB 每年召開兩次面對面會議，每兩周召開一次電話會議。技術顧問委員會由 Thoughtworks 首席技術官 Rebecca Parsons 組建。技術雷達由 Thoughtworks 技術顧問委員會（TAB）創建。本期技術雷達的創建基于 Thoughtworks 技術顧問委員會（TAB）于 2022 年 9 月在西班牙巴塞羅那的線下

5、會議。Rebecca Parsons(CTO)Camilla Falconi CrispimJames LewisScott ShawMartin Fowler(Chief Scientist)Erik DrnenburgMarisa Hoenig Shangqi LiuBharani SubramaniamFausto de la TorreMike MasonBirgitta BckelerHao XuNeal FordBrandon ByarsIan Cartwright Perla Villarreal5中國區技術雷達漢化組：李輝|徐培|楊光|楊洋|邊曉琳|程顯通|鄧奕|樊卓文|符雨菡

6、|高曉明|高語越|郭晨|何蜜|何宇哲|胡鈺涵|黎鵬|李陳澤|李光正|李嘉駿|李思遠|李巖|梁晶|劉鑫|婁麒麟|盧冠昀|馬宇航|孟然|秦睿|史靖雅|孫郁儼|田鵬|田彪|王夢蛟|王鵬熹|王啟瑞|王喬陽|王薇|熊欣|許家文|楊君君|楊旭東|楊陽|楊召|余亞彬|張廣潔|張基|張麗|張真|鄭茗蔓|朱雪晴 Thoughtworks,Inc.All Rights Reserved.機器學習的主流化機器學習（Machine Learning）曾是一片只有一小部分擁有相關工具和資源的幸運兒才能發揮創造的領域。幸運的是，隨著各種規模設備計算能力的增長，開源工具的出現，更嚴格的對隱私和個性化信息保護意識以及法規要求

7、，造就了一個蓬勃發展的生態系統，我們看到機器學習也逐漸成為主流。聯邦學習等技術能夠使 ML 模型為敏感信息提供隱私保障。TinyML 可以讓模型在資源受限的設備上執行，將推理轉移到邊緣，這既可以釋放資源，又可以提高敏感數據的隱私性。Feature Stores 為應用程序開發的模型視圖控制器設計模式提供了類似的好處，使得數據整理、模型訓練和推理之間的分離更為清晰。諸如 Stable Diffusion 之類的公開可用模型既突出了機器學習的驚人能力，也突出了對源數據和道德的關注。機器學習組件也比以往任何時候都更容易連接在一起，從而使得通過自定義業務模型和功能強大的通用模型來創造性的構建機器學習體

8、驗和解決方案更為容易。我們對這一領域的新功能表示贊賞，并熱切期待未來的進步?！捌脚_即產品”的力量在我們的技術雷達會議期間，“平臺”仍然是最常提到的詞語之一，因為這個概念在業界非常普遍。它以許多不同的表現形式出現，包括聚焦業務或領域的平臺，還有基礎設施或者開發者體驗平臺。從根本上說，組織在所有平臺上遇到問題或感到失望的根因是沒有正確地將它們作為產品對待。例如，許多旨在供開發者使用的平臺缺乏在其它類型產品中所期望的用戶調研與上下文分析。平臺所有者需要驗證他們對開發者需求的假設，并響應實際的使用模式。像任何好的產品一樣，平臺需要持續的支持。它必須發展并適應開發者不斷變動的需求。此外，像項目經理和業務

9、分析師等角色所需的經常與傳統應用程序的范圍不同?！捌脚_即產品”的隱喻僅當作為一種實踐而不是一個時髦短語而被完全采納時才會生效。本期主題6 Thoughtworks,Inc.All Rights Reserved.將數據所有權移至邊緣節點我們都知道，任何形式的中心化都會導致限制、瓶頸、和不必要的暴露。所以我們一直在努力尋找打破這些耦合點的新方法，這些方法也在我們技術雷達的更新中被重點提及。而基于無沖突復制數據類型（CRDTs）的研究，使得數據應用可以不使用中心化的數據庫，這種本地優先的軟件/應用技術鼓勵開發者們去考慮圍繞點對點的數據構建應用而不是使用中心化的數據庫。正如機器學習的主流化主題中所展

10、示的一樣，將數據所有權移至邊緣節點能讓開發者更好地利用不同設備的功能，例如面容識別等的許多功能可以在邊緣節點進行，保持所用的數據永久保存在本地。移動端也應該模塊化軟件工程師們已經了解到主要圍繞領域概念和業務功能構建應用架構的價值。雖然根據領域邏輯劃分UI代碼的技術問題仍然很重要，但它已經不是首要問題了。隨著移動應用的成熟，它們通常會變得越來越大，有時會發展為所謂的超級應用程序。這些應用包含許多服務，完全可以視為一個個平臺。雖然有些應用沒有那么大，但多年來積累的很多功能通常也可以分解為各種模塊，許多公司發現移動應用也能從同樣的模塊化方法中受益。模塊化的應用程序可以由多個自主團隊編寫，這帶來了許多

11、有據可查的好處。然而會增加額外復雜度的是，滿足應用商店的上架要求，并且支持原生 iOS，Android 以及基于 web 的版本，還得進行微調以適應每種版本的特點。雖然對于這些移動開發固有的獨特難題，我們看到了更好的框架支持，但總的來說，盡管有好處，許多組織很難將模塊化方法引入到移動開發中。7 Thoughtworks,Inc.All Rights Reserved.3102223151325294142434445464748495031333534363738401514162426171879112021654555665666768697170727374757657596061636

12、48287909293919495969798991021001011038827303239287977788384868589808124819125153586252暫緩暫緩評估評估試驗試驗采納采納TheRadar新的沒有變化挪進/挪出8 Thoughtworks,Inc.All Rights Reserved.采納1.生產路徑圖2.團隊的認知負載3.威脅建模試驗4.BERT5.組件視覺回歸測試6.設計令牌7.用于測試收發郵件的虛擬郵箱服務8.聯邦學習9.增量開發人員平臺10.移動微前端11.CI/CD 流水線的可觀測性12.SLSA13.軟件物料清單評估14.碳效能作為軟件架構的特性1

13、5.CUPID16.GitHub 推送保護17.本地優先應用程序18.指標庫19.服務器端驅動 UI20.SLI 和 SLO 定義為代碼21.模型測試的合成數據22.TinyML23.可驗證憑證暫緩24.沒有“使用原生的遠程工作方法”的衛星式 工人25.默認選擇 SPA26.膚淺的云原生采納27.Backstage28.Delta Lake試驗29.AWS 數據庫遷移服務30.Colima31.Databricks Photon32.DataHub33.DataOps.live34.eBPF35.Feast36.Monte Carlo37.Retool38.Seldon Core39.Tele

14、port40.VictoriaMetrics評估41.Bun42.Databricks Unity Catalog43.Dragonfly44.Edge Impulse45.GCP Vertex AI46.Gradient47.IAM Roles Anywhere48.Keptn49.OpenMetadata50.OrioleDB暫緩技術平臺TheRadar Thoughtworks,Inc.All Rights Reserved.采納51.Great Expectations52.k6試驗53.Apache Superset54.AWS Backup 文件庫鎖定55.AWS Control

15、Tower56.Clumio Protect57.Cruft58.Excalidraw59.Hadolint60.Kaniko61.Kusto 查詢語言62.Spectral63.Styra Declarative Authorization Service64.監視項目構建的 xbar評估65.Clasp66.Databricks Overwatch67.dbtvault68.git-together69.Harness 云服務成本管理70.Infracost71.Karpenter72.Mizu73.Soda Core74.Teller75.Xcode Cloud暫緩76.在線格式化或代碼

16、解析服務采納77.io-ts78.Kotest79.NestJS80.React Query81.Swift Package Manager82.Yjs試驗83.Azure Bicep84.Camunda85.Gradle Kotlin DSL86.Jetpack Media387.Ladle88.Moshi89.Svelte評估90.Aleph.js91.Astro92.BentoML93.Carbon Aware SDK94.Cloudscape95.Connect96.跨設備 SDK97.Cypress 組件測試98.JobRunr99.Million100.Soketi101.Stab

17、le Diffusion102.合成數據保險庫暫緩103.Carbon工具語言和框架TheRadar Thoughtworks,Inc.All Rights Reserved.技術310222315132529414243444546474849503133353436373840151416242617187911202165455566566676869717072737475765759606163648287909293919495969798991021001011038827303239287977788384868589808124819125153586252暫緩暫緩評估評估試

18、驗試驗采納采納采納1.生產路徑圖2.團隊的認知負載3.威脅建模試驗4.BERT5.組件視覺回歸測試6.設計令牌7.用于測試收發郵件的虛擬郵箱服務8.聯邦學習9.增量開發人員平臺10.移動微前端11.CI/CD 流水線的可觀測性12.SLSA13.軟件物料清單評估14.碳效能作為軟件架構的特性15.CUPID16.GitHub 推送保護17.本地優先應用程序18.指標庫19.服務器端驅動 UI20.SLI 和 SLO 定義為代碼21.模型測試的合成數據22.TinyML23.可驗證憑證暫緩24.沒有“使用原生的遠程工作方法”的衛星式 工人25.默認選擇 SPA26.膚淺的云原生新的挪進/挪出沒有

19、變化 Thoughtworks,Inc.All Rights Reserved.1.生產路徑圖采納盡管生產路徑圖自從持續交付被編著時在 Thoughtworks 就是一種近乎普遍的實踐，但是我們經常會遇到一些不熟悉生產路徑圖實踐的組織。這一活動經常由一群跨功能團隊的人在工作坊中完成（包括參與設計、開發、發布與運營軟件的所有人），他們圍在同一張白板前面（或者是一個虛擬的等價物）。首先，按照順序把流程的步驟羅列出來，從開發階段一直到發布上產的所有路徑。然后，主持一個會議來獲取更多的信息和痛點。我們最常見的技術是基于價值流圖，盡管有很多具有同等價值的流程圖變種。這項活動經常會讓參與者眼界大開，因為他

20、們識別出了延遲，風險和不一致的地方，并且可以用可視化的陳述來持續改進構建和部署的流程。我們認為這是一項很基本的技術，所以當我們發現在之前的技術雷達中我們沒有提到它的時候，我們感到非常驚訝。2.團隊的認知負載采納在為組織重新設計業務敏捷性和交付速度時，團隊交互是一個關鍵概念。這些交互將反映在正在構建的軟件中（參見康威定律），并表明團隊可以如何有效地自主為客戶提供價值。我們的建議是關注團隊的設計和互動方式。因為我們相信組織設計和團隊交互會隨著時間而發展，所以我們認為衡量和跟蹤團隊的認知負載尤為重要，這可以讓你理解團隊構建、測試和維護其服務的難易程度。我們一直在使用一個模板來評估團隊的認知負載，該模

21、板基于高效能團隊模式（Team Topologies）作者的想法。在與客戶溝通和重新設計組織時，應用本書的概念所產生的積極影響給我們留下了深刻的印象。作者推薦了一種簡單但強大的組織設計方法，僅確定四種類型的團隊和三種交互模式；這有助于減少組織內的歧義，并為團隊、利益相關者和領導層提供一個通用詞匯來描述和設計團隊的工作。為了實施組織設計變更，我們設計了理想的未來團隊拓撲結構，應用任何技術/人員限制（即員工不足），然后形成最終的結構。這使我們能夠更好地為客戶提供建議，并通過比較現有/未來的團隊結構來預測我們是否確實在改善認知負載。3.威脅建模采納我們繼續推薦團隊實施威脅建模一系列有助于在開發過程中

22、發現潛在威脅并對其進行分類的技術，但是我們想要強調的是，這件事不是只在項目開始時做一次就能一勞永逸的，團隊需要避免 security sandwich 現象。這是因為，在任何軟件的整個生命周期中，由于外部事件以及需求和架構的調整，可能會出現新的威脅，而現有的威脅將繼續發展。這就意味著，威脅建模需要定期重復，重復的頻率視情況而定，需要綜合考慮諸多因素，例如執行的成本和對業務的潛在風險等。如果結合其他技術使用，例如建立跨功能的安全需求來發現項目所采用的技術有什么公共風險，以及使用自動化安全掃描，這時威脅建模將變得非常有用處。4.BERT試驗自我們上次在技術雷達中談到 BERT（來自變換器的雙向編碼

23、器表征量）之后，我們團隊已經成功地在一些自然語言處理（NLP）項目中使用了它。在其中一個項目里，當我們把默認的 BERT 分詞器換成一個經過領域訓技術12 Thoughtworks,Inc.All Rights Reserved.練的詞塊（word-piece）分詞器，再去處理那些含有品牌名稱或者維度之類名詞的查詢任務時，我們看到了顯著的改進。雖然 NLP 有一些新的轉換模型，但 BERT 憑借優秀的文檔以及活躍的社區支持，更加通俗易懂，而且我們也一直發現它在企業級 NLP 背景下非常有效5.組件視覺回歸測試試驗視覺回歸測試是很有用的強大工具，值得被您收進工具箱。但是在整個頁面上使用視覺回歸測

24、試的成本非常高。我們看到隨著 React 和 Vue 等基于組件的框架逐漸興起，組件視覺回歸測試也越來越流行。這項技術能確保在應用程序中不會引入非必要的視覺元素，從而很好的維持了投入和產出之間的平衡。在我們的實踐里，組件視覺回歸測試很少誤測，而且有助于改善架構風格，通過和 Vite 以及 webpack 的模塊熱替換（HMR）功能共同使用，還可以視之為測試驅動開發應用于前端開發領域的范式轉變。6.設計令牌試驗當面臨如何跨多種尺寸設備和平臺一致地使用設計系統的挑戰時，Salesforce 的團隊提出了設計令牌這個概念。令牌將諸如顏色和字體等值存儲在一個中心位置。這使得將選項與決策分開成為可能，并

25、且顯著改善了團隊之間的協作。設計令牌并不是新事物，但隨著 Tailwind CSS 和 Style Dictionary 等工具的引入，我們看到設計令牌被更頻繁地使用。7.用于測試收發郵件的虛擬郵箱服務試驗使用真實電子郵箱的測試賬戶，或使用 SMTP（簡單郵件傳輸協議）服務器進行測試仍然是較為常見的軟件測試方法。然而，使用真實的服務進行測試會帶來測試郵件將被發送到真實的人的風險，也常常會使自動集成測試變得復雜。我們完全可以使用虛擬 SMTP 服務器來測試郵件發送，它記錄了發送電子郵件的請求，但并沒有實際發送。在這個領域存在多個開源工具，比如 fake-smtp-server，它提供了 Web

26、UI 來展示郵件，便于可視化測試；以及 mountebank，它提供了 REST API 來獲取已發送的郵件，便于集成測試。我們建議探索這種技術，以減少風險，提高測試效率。8.聯邦學習試驗我們看到許多客戶項目正在使用聯邦學習（ML）。傳統上機器學習模型訓練時需將數據放在集中運行模型訓練算法的地址。在隱私角度上，這存在問題，特別是當訓練數據包括敏感或者可用于身份識別信息時；用戶也許不愿意分享數據，當地的數據保護法律也可能不允許我們將數據轉移至一個中心化的位置。聯邦學習是一個去中心化的技術，它使模型可以在大量不同來源的數據集上訓練，并讓數據保持在遠端，例如用戶的設備上。盡管網絡帶寬和設備的算力限制

27、目前仍是這項技術重大的挑戰，但是我們喜歡聯邦學習的思路，讓用戶可以完全控制自己的個人信息。技術13 Thoughtworks,Inc.All Rights Reserved.9.增量開發人員平臺試驗自從 2017 年以來，我們幾乎每一期技術雷達都寫過關于開發人員平臺以及如何構建它們的內容。與此同時，團隊拓撲學這本書還很好地描述了一個理想的平臺，即用“自服務的 API、工具、服務和知識”來支持開發人員。然而，我們經?？吹綀F隊對于實現這種平臺的愿景操之過急。事實上，構建一個增量開發平臺才是關鍵所在。團隊拓撲學建議在任何特定階段，都努力去實現一個所謂的“最小可行平臺”，這個平臺的第一版甚至可以是一系

28、列的 wiki 文檔。下一個增量可以通過提供模版或允許成員創建請求來提高服務水平。進一步的增量可以引入自服務 API，但前提是有價值。簡而言之，盡管我們小心地反對全量工單驅動的平臺運營模式，但從零到自服務是另一個極端。調整你自己的步調，將產品管理思維應用于內部平臺并逐步增量地建立它。10.移動微前端試驗自從 2016 年在技術雷達中介紹微前端以來，我們已經看到 Web UI 廣泛地采用它們。然而，最近我們看到一些項目把這種架構風格也拓展到了移動微前端。當應用程序變得足夠龐大與復雜時，就有必要將開發工作分配給多個團隊。這提出了圍繞團隊自治、倉庫結構與集成框架的許多挑戰。過去，我們提到過 Atla

29、s 與 BeeHive，但是這些框架未能獲取關注而且也不再處于活躍開發狀態。最近的方法包括用于將多個團隊的工作集成到單個應用程序中的 Tuist 或 Swift 包管理器。但根據我們的經驗，團隊最終經常會實現自己的集成框架。雖然我們毫無疑問看到了在擴充移動開發團隊規模時對模塊化的需求，但是對微前端的需求卻不太確定。這是因為盡管微前端意味著團隊與頁面或組件之間的直接對應關系，但是這種結構卻有可能最終導致業務領域上下文的職責模糊，由此增加團隊認知負載。我們的建議是遵循良好、整潔的應用程序設計，當規模擴大為多個團隊時采納模塊化，僅當模塊與業務領域高度對齊時才采用微前端架構。11.CI/CD 流水線的

30、可觀測性試驗可觀測性實踐已經將對話從監測通俗易懂的問題轉換為幫助解決分布式系統中的未知問題。通過應用 CI/CD 流水線的可觀測性，我們已經看到在傳統生產環境之外采納這種立場以幫助優化測試與部署瓶頸的成功。復雜的流水線會在運行太慢或遭受非確定性影響時給開發者帶來摩擦，進而減少關鍵反饋循環并且阻礙開發者效率。此外，它們作為關鍵部署基礎設施的角色在快速部署周期中產生了壓力點，就像一些組織在應對最近的 log4shell漏洞時所發生的那樣。追蹤的概念能夠很好地轉移到流水線上：子跨度抓取構建每個階段的信息，而不是抓取服務調用級聯。在分布式架構中用于分析調用流的瀑布圖同樣可以有效地幫助我們識別流水線瓶頸

31、，甚至是那些扇入扇出的復雜流水線。這使得針對性大幅提高的優化工作成為可能。盡管此項技術適用于任何追蹤工具，但是 Honeycomb 支持一個名為 buildevents 的工具，其有助于抓取流水線追蹤信息。一種替代方案，即抓取已經由 CI/CD 平臺暴露的信息，由 buildviz（由一位 Thoughtworker 構建并維護）采納，允許在不更改步驟配置文件自身的情況下進行相似的調查。技術14 Thoughtworks,Inc.All Rights Reserved.12.SLSA試驗隨著軟件復雜性的不斷增加，軟件依賴項的威脅路徑變得越來越難以守護。軟件工件供應鏈層級，又稱 SLSA（讀作“

32、salsa”），是一個由聯盟組織策劃的，為組織機構提供防范供應鏈攻擊的指南集。該框架衍生于一個 Google多年來一直使用的內部指南。值得稱贊的是，SLSA 并沒有承諾提供“銀彈”，即僅使用工具確保供應鏈安全的方法，而是提供了一個基于成熟度模型的具體威脅和實踐的清單。這個威脅模型是很容易理解的，其中包含了真實世界發生的攻擊實例，并且要求文檔中也提供了指南，幫助組織基于日漸增強的穩健性水平為其行動措施排定優先級，以改善他們供應鏈的安全態勢。自我們第一次在技術雷達中提到 SLSA 以來，它已經通過示例，圍繞軟件認證增添了很多細節，以跟蹤如構建出處等問題。我們的團隊發現 SLSA 在具體執行指導和更

33、高層次對供應鏈威脅的認知之間取得了良好的平衡。13.軟件物料清單試驗在保障系統安全性的壓力不變且總體安全威脅不減的情況下，一個機器可讀的軟件物料清單（SBOM）可以幫助團隊掌握他們所依賴的庫中的安全問題。隨著美國總統令的發布，業界對SBOM的概念和如何創建SBOM都有了清晰的認識，例如國家標準與技術研究院（NIST）也針對如何執行總統令提出了更詳細的建議?，F在我們已經具備了在項目中使用 SBOM 的生產經驗，項目范圍從小型企業到大型跨國公司，甚至是政府部門，而且我們確信它能為我們提供益處。更多的機構和政府部門應當考慮索取正在使用的軟件的SBOM。隨著Firebase Android BOM等可

34、以自動羅列應用軟件 BOM 中依賴庫的新工具的不斷出現，這項技術也將持續強化。14.碳效能作為軟件架構的特性評估可持續發展是一個需要企業持續關注的話題。在軟件開發領域，可持續發展的重要性日益顯著，并且我們也可以看到出現了很多不同的達成途徑。例如，在構建軟件碳足跡方面，我們建議對碳效能作為軟件架構的特性進行評估。一個重視碳效能的架構會將碳效率作為架構設計和基礎設施選型的考慮因素，以最大限度地減少能源消耗，進而實現減少碳排放。該領域的測量工具和開發建議也日趨成熟，使得開發團隊可以將碳效能與性能、可擴展性、財務成本和安全性等其他因素一起進行考量。就像軟件架構中的所有因素一樣，碳效能應該被視為一種權衡

35、。我們建議將碳效能視為構成架構的一整套質量屬性中的一個附加特性。因為這類特性應由組織目標驅動并劃分優先級，而不應該留給一小部分專家孤立地思考。15.CUPID評估你應該如何編寫好的代碼？如何判斷自己是否寫了好的代碼？作為軟件開發者，我們總是在尋找一些自然易記的規則、原則和模式，以便在討論如何編寫簡單的、易修改的代碼時，我們有統一的語言和價值觀。Daniel Terhorst-North 最近嘗試為好代碼創建了一個類似于檢查表的東西。他認為與其拘泥于像 SOLID 這樣一套規則，不如使用一組特性作為目標。他設計出了名為 CUPID 的特性組，來描述為了寫出“令人愉悅”的代技術15 Thought

36、works,Inc.All Rights Reserved.碼，我們需要做出哪些努力：在該特性指導下的代碼應該是可組合的，遵循 Unix 哲學的，可預測的，風格自然的以及基于領域的。16.GitHub 推送保護評估意外泄露機密似乎是一個老生常談的事故，也出現了像 Talisman 這樣的工具來幫助解決這個問題。在此之前，擁有高級安全許可證的 GitHub Enterprise Cloud 用戶可以對其帳戶啟用安全掃描，意外提交和推送的任何機密（API 密鑰、訪問令牌、憑據等）都會觸發警報。GitHub 推送保護更深入了一步，并將其提前到了開發工作流程中，如果更改被推送的時候檢測到有機密，則直接

37、拒絕這次推送。這需要為組織進行配置，當然僅適用于許可證持有者，但歡迎提供額外的保護以防止泄露機密。17.本地優先應用程序評估在集中式應用程序中，服務器上的數據是可信單一數據源，對數據的任何修改都必須經由服務器完成，本地數據只是服務器數據的副本。這似乎是實現軟件的多人協作自然且必然的選擇。本地優先應用程序，或本地優先軟件，是一組即能夠實現多人協作，且可以使數據所有權本地化的軟件設計原則。它優先使用本地存儲和本地網絡，而不是遠程數據中心或云服務器。無沖突復制數據類型（CRDT）和點對點（P2P）網絡等技術有可能成為實現本地優先軟件的基礎技術。18.指標庫評估指標庫，有時也被稱作無頭商業智能（BI）

38、，是一種將指標的定義與其在報表和可視化中的使用相解耦的中間層。在傳統意義上講，指標定義在商業智能（BI）工具的上下文中。但是這樣的做法會導致重復與不一致，因為不同的項目組可能將指標用于不同的上下文中。通過指標庫解耦指標的定義，便可以清晰且一致地在多個報表、可視化甚至嵌入式分析中復用指標。這并不是一項新技術；例如，Airbnb 在幾年前就引入了 Minerva。不過，隨著越來越多的工具開箱即用地支持指標庫，指標庫在數據和分析生態的影響力越來越大。19.服務器端驅動 UI評估服務器端驅動 UI 仍然是移動開發圈的一個熱議話題，因為這項技術允許移動端開發者利用更快的變更周期，而不違反應用商店關于重新

39、驗證移動應用的任何政策。服務器端驅動UI將渲染分離到移動應用程序的一個通用容器中，而每個視圖的結構和數據由服務器提供。這意味著對于過去那些需要經歷一次應用商店發布之旅的修改，現在只需要簡單改變服務器發送的響應數據即可實現。雖然一些非常大的移動應用團隊已經利用這種技術取得了巨大的成功，但它也需要大量的投入來建立和維護一個復雜的私有框架。這樣的投入需要一個令人信服的商業案例。在此之前，最好謹慎行事。我們的確陷入過某種過度配置的可怕困境，并沒有真的獲得預期的收益。但在 Airbnb 和 Lyft 等巨頭的背書下，我們很可能會看到一些有用的框架出現，有助于降低這種復雜度。這一領域值得關注。技術16 T

40、houghtworks,Inc.All Rights Reserved.20.SLI和SLO定義為代碼評估自從谷歌首次將服務質量指標（SLIs）和服務質量目標（SLO）作為其網站可靠性工程（SRE）實踐的一部分推廣以來，Datadog、Honeycomb 和 Dynatrace 等觀察性工具開始將 SLO 監控納入其工具鏈。OpenSLO 是一個基于 Kubernetes 使用的 YAML 格式聲明式、中立的規范語言新興的，且允許將 SLI 和 SLO 定義為代碼的標準。雖然該標準仍然很新，但我們看到了一些令人鼓舞的勢頭，比如 Sumo Logic 公司貢獻了 slogen 工具來生成監控和儀

41、表盤。我們對在代碼中對 SLI 和 SLO 定義進行版本化的承諾，和將可觀察性工具作為所部署服務的 CI/CD 流水線一部分這一更新感到興奮。21.模型測試的合成數據評估在我們本期技術雷達的討論中，出現了幾個用于生成合成數據的工具和應用。我們發現，隨著工具的成熟，模型測試的合成數據成了一項強大而且有廣泛應用的技巧。在驗證機器學習模型判別能力的過程里，合成數據雖然尚不能取代真實數據，但也有相當廣泛的使用場景。例如，合成數據可以用于預防小概率事件下模型徹底失效，或者在不暴露個人隱私信息的前提下對數據流水線進行測試。在探索缺乏真實數據的邊緣場景以及確認模型偏差時，合成數據也很有用處。有一些有助于生成

42、數據的工具，例如 Faker 和 Synth 可以生成服從預期統計特性的數據，Synthetic Data Vault 等工具可以依照輸入數據集特性來生成數據。22.TinyML評估我們仍舊為 TinyML 這項技術和它在構建可以運行在低功耗和移動設備上的機器學習（ML）模型的能力而感到興奮。時至今日，運行機器學習（ML）模型仍然需要高昂的計算成本，并且在某些情況下還需要使用專用硬件。雖然模型的創建仍然大致屬于上述情況，但可以通過一種方式創建模型，使它們能夠在小型、低成本和低功耗設備上運行。如果你一直在考慮使用 ML 但苦于計算能力或網絡環境的限制而放棄，那么這種技術值得你去 評估。23.可驗

43、證憑證評估當我們兩年前第一次把它納入雷達時，可驗證憑證是一個有趣的標準，有著一些潛在的應用前景，但它并沒有在愛好者群體之外廣為人知。當涉及到將負責實施該標準的證書授予機構時，如州級政府等，情況更是如此。自疫情以來的兩年后，隨著對加密安全、尊重隱私和可由機器驗證的電子憑證的需求的增長，政府開始意識到可驗證憑證的潛力。我們現在開始看到可驗證證書出現在我們與公共部門客戶的合作中。W3C 標準以憑證持有者為中心，這與我們使用物理憑證時的經驗相似：用戶可以將其可驗證憑證放在自己的數字錢包中，并在任何時候向任何人展示，而無需得到憑證發行者的許可。這種去中心化的方法也使用戶能夠更好地管理和有選擇地披露自己的

44、信息，這大大改善了數據隱私的保護。例如，在零知識證明技術的支持下，你可以在不透露你的生日情況下構建一個可驗證憑證來證明你是一個成年人。值得注意的是，盡管許多基于可驗證憑證的去中心化身份解決方案依賴于區塊鏈技術，但區塊鏈并不是所有可驗證憑證實施的先決條件。技術17 Thoughtworks,Inc.All Rights Reserved.24.沒有“使用原生的遠程工作方法”的衛星式工人暫緩術語“遠程團隊配置”并不只是描述一種配置；它包含了多種模式和口味。許多團隊最近都在改變模式。他們正從新冠疫情下被迫采取的“每個人總是遠程”的工作模式中走出來，轉而采用（通常是輪流）衛星式工人的模式，即部分團隊在

45、同一地點辦公，部分團隊遠程工作。我們看到他們中的許多人沒有正確考慮這對工作方式意味著什么。沒有“使用原生的遠程工作方法”的衛星式工人回到了優先考慮同地辦公的工作方式。在有衛星式工人的配置中，重要的是仍然默認使用“原生的遠程工作方法”。例如，如果團隊中在同一地點工作的人一起參加會議，他們仍然應該在各自的筆記本電腦上參與數字協作或會議聊天。團隊需要意識到排斥他們的衛星工人和創造孤島和排斥感的風險。如果你知道總是有至少一個衛星團隊成員，那么默認的工作方式應該假定是遠程的。25.默認選擇 SPA暫緩團隊搭建網站時會默認選擇單頁面應用（SPA）的普遍現象讓我們擔心人們甚至沒意識到 SPA 原本只是一種架

46、構風格時，就立即進行了項目的框架選型。SPA 會招致傳統基于服務器的網站所不具備的復雜性：譬如搜索引擎優化，瀏覽歷史管理，網站分析，首頁加載時間等。我們需要適當地分析和考慮，來確定這種復雜性是出于業務需求還是用戶體驗，以此做出權衡。我們通?？床坏綀F隊去進行這種權衡分析，即使是在業務需求不能證明這種使用是合理的情況下，也盲目地接受了默認使用 SPA 的復雜性。事實上，我們已經開始注意到許多新的開發人員甚至都不知道有替代的方法，因為他們整個職業生涯都是在類似 React 這樣的框架中度過的。我們相信，許多網站都會受益于服務端邏輯的簡潔性，并且我們從例如 Hotwire 這種有助于減少用戶體驗差異的

47、技術中受到了鼓勵。26.膚淺的云原生暫緩“云原生”一詞最初用于描述最大限度利用公有云托管的架構。例如由許多小型、無狀態和協作流程組成的分布式架構，以及具有高度自動化的構建、測試和部署能力的系統。然而，我們注意到越來越多膚淺的云原生設計，簡單地大量使用云供應商提供的專有服務，而沒有注意到應用程序其實是大單體、脆弱且笨重的。要注意的是，無服務函數本身并不能使應用程序更具彈性或更易于維護。云原生實際上是架構設計，而非對于實現方式的 選擇。技術18 Thoughtworks,Inc.All Rights Reserved.平臺31022231513252941424344454647484950313

48、3353436373840151416242617187911202165455566566676869717072737475765759606163648287909293919495969798991021001011038827303239287977788384868589808124819125153586252暫緩暫緩評估評估試驗試驗采納采納采納27.Backstage28.Delta Lake試驗29.AWS 數據庫遷移服務30.Colima31.Databricks Photon32.DataHub33.DataOps.live34.eBPF35.Feast36.Monte

49、Carlo37.Retool38.Seldon Core39.Teleport40.VictoriaMetrics評估41.Bun42.Databricks Unity Catalog43.Dragonfly44.Edge Impulse45.GCP Vertex AI46.Gradient47.IAM Roles Anywhere48.Keptn49.OpenMetadata50.OrioleDB暫緩新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.27.Backstage采納在一個日漸數字化的世界里，大型組織怎樣提高開發者的效率往往是資深領導

50、們的核心關注點?？偟膩碚f我們已經足夠意識到了開發者門戶的價值，特別是 Backstage 的價值，我們非常愿意在采納環中推薦它。Backstage是由Spotify開發的一款能提升整個組織內的軟件資產發現的開源開發者門戶平臺。它使用了存放在代碼庫中的Markdown TechDocs 來追蹤每個服務，這很好地平衡了中心化發現和分布式資產所有權的需求。Backstage支持軟件模版，這可以加速新項目的開發。它還支持插件架構，能夠增強組織基礎設施生態系統的可擴展性和適應性。Backstage 服務目錄使用 YAML 文件來追蹤組織生態系統中所有軟件的所有權和元數據；它甚至可以讓你追蹤第三方的 Sa

51、aS 軟件，通常來說這么做需要追蹤的權限。28.DeltaLake采納Delta Lake 是由 Databricks 實現的開源存儲層，旨在將 ACID 事務處理引入到大數據處理中。在使用了Databricks 的 data lake 或 data mesh 的項目中，我們的團隊更喜歡使用 Delta Lake 存儲，而不是直接使用AWS S3 或 ADLS 等文件存儲類型。Delta Lake 此前一直是 Databricks 的閉源項目，最近成為了開源項目，并且可以在 Databricks 之外的平臺使用。但是，我們只建議使用 Parquet 文件格式的 Databricks 項目將 D

52、elta Lake 作為默認選擇。Delta Lake 促進了需要文件級事務機制的并發數據讀/寫用例的發展。我們發現 Delta Lake 與 Apache Spark batch 和 micro-batch 的無縫集成 API 非常有用，尤其是其中諸如時間旅行（在特定時間點訪問數據或還原提交）以及模式演變支持寫入等功能，盡管這些功能有一些限制。29.AWS 數據庫遷移服務試驗我們的許多團隊已成功使用 AWS 數據庫遷移服務（DMS）將數據遷移到 AWS 或從 AWS 遷移數據。在我們的一項數字化轉型項目中，當我們將數據從 Microsoft SQL 服務遷移到 AWS 關系數據庫服務（RDS

53、）PostgreSQL實例時，我們以幾乎零宕機時間切換到了新系統。這次轉型涉及許多部分，需要跨多專業團隊進行規劃和協調，然而對于數據遷移來說，我們對 DMS 非常滿意。它自動管理所有必需資源的部署、管理和監控。經過多年的發展，DMS 已經很成熟，可以支持多種來源和目標數據庫，我們也會繼續支持它。30.Colima試驗Colima 正在成為 Docker Desktop 的一個流行的開源替代方案。它通過 Lima VM 的方式提供 Docker 容器運行時，在 macOS 上配置 Docker CLI 并處理端口轉發和卷掛載。Colima 使用 containerd 作為容器運行時，這也是大多數

54、托管 Kubernetes 服務采用的容器運行時，這一方案提升了開發與生產環境的一致性。通過 Colima，你可以輕松地使用和測試containerd的最新特性，例如容器鏡像的懶加載。我們在項目中使用Colima已經取得了不錯的效果。在使用 Kubernetes 時，我們也使用 nerdctl，這是一個與 Docker 兼容的 containerd CLI。由平臺20 Thoughtworks,Inc.All Rights Reserved.于 Kubernetes 已經不再將 Docker 作為容器運行時，而且大多數托管服務（EKS、GKE 等）都在追隨它的腳步，因此更多的人將會使用 con

55、tainerd 這類原生工具，使得像 nerdctl 這樣的工具更加重要。在我們看來，Colima有著強大的潛力，并會成為 Docker Desktop 的首選替代方案。31.DatabricksPhoton試驗自 Databricks 9.1 LTS（長期支持版）開始，新運行時 Databricks Photon 開始可用，它是一個使用 C+重新從底層構建的替代品?，F在我們的許多團隊在生產中使用了 Photon，并對它的性能提升和因此帶來的成本節約感到滿意。實際使用中的提升和成本變化受到包括數據集大小和事務類型在內的多種因素影響，所以我們推薦在決定使用 Photon 前進行試驗以獲得數據進行

56、比較，而非直接用于真實的工作負載。32.DataHub試驗自從我們第一次在技術雷達中提及數據的可發現性以來，LinkedIn 已經將 WhereHows 進化為 DataHub，一個通過可擴展的元數據系統實現數據可發現性的下一代平臺。與爬取和拉取元數據不同，DataHub 采用了基于推送的模式。數據生態系統中各個組件，都可以通過 API 或者流（stream）向中心化的平臺上發布元數據。這種基于推送的數據集成，將數據發現所有權從中心實體轉移到各個團隊，使他們對自己的元數據負責。因此，我們已成功將 DataHub 用于組織層面的元數據存儲庫和多種自維護的數據產品入口。當使用它時，請確保它足夠輕量

57、并避免讓它滑坡成對共享資源的中心化控制系統。33.DataOps.live試驗DataOps.live 是一個可在 Snowflake 中實現環境自動化的數據平臺。受 DevOps 實踐的啟發，DataOps.live通過采用持續集成和持續交付（CI/CD）、自動化測試、可觀測性和代碼管理，讓你可以像對待任何其他 web 平臺一樣對待數據平臺。你可以立即回滾更改而不會影響數據，或者從完全故障中恢復，并在幾分鐘或幾小時而不是幾天內重建新的 Snowflake 租戶。我們的團隊在使用 DataOps.live 的過程中體驗良好，因為它讓我們能夠在 Snowflake 之上構建數據產品時快速迭代。3

58、4.eBPF試驗Linux 內核在多年前就內置了擴展的伯克利數據包過濾器（eBPF），它是一個可以將過濾器附加到特定套接字能力的虛擬機。但是 eBPF 的能力遠遠超出了包過濾的范圍，它允許在內核中的不同點位觸發自定義腳本，并且開銷非常小。通過在操作系統內核中運行沙箱程序，開發人員可以通過 eBPF 程序給操作系統運行時添加額外的功能。在一些項目需要進行系統調用層的故障排除和剖析時，我們的團隊發現像 bcc 和 bpftrace 這樣的工具會簡化工作。eBPF 也可用于可觀測性和網絡基礎設施，例如 Cilium 項目可以在 Kubernetes 中以無 sidecar 開銷平臺21 Though

59、tworks,Inc.All Rights Reserved.的方式實現流量負載平衡和可觀察性，Hubble 項目在其基礎上加強了安全和流量可觀察性。Falco 項目使用eBPF 進行安全監控，Katran 項目使用 eBPF 建立更有效的 L4 負載平衡。eBPF 社區正在迅速發展，并且我們看到了與可觀察性領域越來越多的協同作用。35.Feast試驗Feast 是一個用于機器學習的開源 Feature Store。它具有幾個有用的特性，包括生成時間點（point-in-time）正確的特征集以避免在訓練時將容易出錯的未來特征值泄露給模型，以及支持流數據源與批數據源。然而，它目前僅支持具有時間

60、戳的結構化數據，因此，如果你在模型中處理非結構化數據，那么 Feast 可能并不適用。我們已成功地大規模采用 Feast 作為模型訓練時的離線存儲與預測時的在線存儲。36.MonteCarlo試驗Monte Carlo 是一個數據可觀測性平臺。它使用機器學習模型，可以推斷和學習數據，識別問題并在出現問題時通知用戶。它使我們的團隊能夠跨 ETL 流水線、數據湖、數據倉庫和商業智能（BI）報告維護數據質量。憑借監控儀表板即代碼、中央數據目錄和字段級沿襲等功能，我們的團隊發現 Monte Carlo 是整體數據治理的寶貴工具。37.Retool試驗在之前的技術雷達中，我們曾建議評估限界低代碼平臺，將

61、其作為一種將低代碼解決方案應用于極少數領域的特定用例的方法。我們已經看到這個方向越來越受歡迎，特別是低代碼平臺 Retool，我們的團隊用它來為內部用戶構建解決方案，主要用于數據的查詢和可視化。它使得內部用戶可以更快地制作非關鍵業務的只讀解決方案。據報告顯示，Retool 的主要優勢在于它的用戶界面組件，以及與公共數據源快速便捷集成的能力。38.SeldonCore試驗Seldon Core 是一個在 Kubernetes 集群上打包、部署、監控和管理機器學習模型的開源平臺。它針對一些機器學習框架提供開箱即用的支持，你可以很容易的通過各種預打包的推理服務器、定制的推理服務器、以及語言包裝器將你

62、的模型容器化。同時，借助 Jaeger 的分布式追蹤能力，并通過 Alibi 實現模型可解釋性，Seldon Core 解決了阻礙機器學習部署階段某些最后一公里的難題，因此我們的數據團隊非常喜歡它。39.Teleport試驗Teleport 是訪問零信任網絡基礎設施的工具。傳統的設置需要復雜的策略或跳板機來限制對關鍵資源的訪問，然而，Teleport 通過統一的訪問平面和取代了跳板機、VPN 或共享憑證的細粒度授權控制來簡化了這些設置。平臺22 Thoughtworks,Inc.All Rights Reserved.Teleport 被實現為單個二進制文件，并且開箱即用地支持多種協議（包括

63、SSH、RDP、Kubernetes API、MySQL、MongoDB 和 PostgreSQL 連接協議），使用戶可以輕松設置和管理跨 Linux、Windows 或 Kubernetes 環境的安全訪問。自從我們第一次在技術雷達中提到它以來，已經有一些團隊使用了 Teleport，整體的積極體驗促使我們強調這一平臺。40.VictoriaMetrics試驗現代可觀察性依賴于收集和匯總一組詳盡的細粒度指標，以充分理解、預測和分析系統行為。但面對由大量冗余，協作進程和主機組成的云原生系統時，由于基數（唯一時間序列數）會隨著每個額外的服務、容器、節點、集群等呈指數增長，現代可觀察性的應用顯得相

64、對笨重。對于這些高基數的數據，我們發現 VictoriaMetrics表現出眾。VictoriaMetrics 尤其適用于運行由 Kubernetes 托管的微服務架構，它的 operator 使團隊可以輕松地以自助服務的方式實現自我監控。我們還喜歡它的組件化架構以及即使在中央服務器不可用時也能繼續收集指標的能力。雖然我們的團隊對 VictoriaMetrics 很滿意，但云原生的可觀察性是一個快速發展的領域，我們建議也同時關注其他高性能的、Prometheus 兼容的時間序列數據庫，例如 Cortex 或 Thanos。41.Bun評估Bun 是一個新的 JavaScript 運行時，與 N

65、ode.js 或 Deno 相似。然而不同于 Node.js 或 Deno 的是，Bun 使用 WebKit 的 JavaScriptCore 構建，而不是 Chrome 的 V8 引擎。Bun 被設計為 Node.js 的直接替代品，它是一個單獨的二進制文件（使用 Zig 編寫），能夠充當 JavaScript 和 TypeScript 的打包器、轉譯器（transpiler）與包管理器。Bun 目前正在 beta 測試，所以我們可以預計有一些漏洞或是與一些 Node.js 庫的兼容性問題。然而，Bun 是從頭開始構建的并且帶有一些優化，包括快速啟動和改進的服務端渲染，我們認為它值得評估。4

66、2.DatabricksUnityCatalog評估Databricks Unity Catalog 是一種可以用于 lakehouse 中文件、表或者機器學習模型等資產的數據治理方案。盡管你可以在企業數據治理領域中找到很多平臺，但如果你已經在使用其他 Databricks 解決方案，那你更應該了解一下 Unity Catalog。我們想強調的是，雖然這些治理平臺通常會采用一個集中式的解決方案，以更好地維持不同工作空間和工作負載的一致性，但治理責任應該通過使各個團隊分別治理自己的資產而統一起來。43.Dragonfly評估Dragonfly是一個可兼容Redis和Memcached API的新

67、型內存數據庫。它利用Linux新有的io_uring API實現I/O，并在多線程、無共享架構的基礎上實現新型的算法和數據結構。因為這些明智的實現方案選擇，Dragonfly在性能方面取得了令人印象深刻的結果。盡管 Redis 仍然是我們對內存數據庫解決方案的默認選項，但我們認為 Dragonfly 是一個值得評估的選項。平臺23 Thoughtworks,Inc.All Rights Reserved.44.EdgeImpulse評估在往期的技術雷達中，我們寫過 TinyML。TinyML 是在帶有板載傳感器的小型設備上運行經過訓練的模型，在不經過云端的情況下做出決策或提取特征的實踐。Edg

68、e Impulse 是一個端到端托管平臺，用于開發運行在如微控制器等小型邊緣設備上的優化模型。該平臺指導開發人員完成整個流程，包括收集并給訓練數據打標簽的任務。你可以輕松地上手，先在手機上進行數據收集和運行分類器，而在更強大的云托管環境中進行模型訓練和優化。由此產生的識別算法還可以優化、編譯并上傳到廣泛的微控制器架構中。雖然 Edge Impulse 是一家商業公司，但該平臺對開發人員是免費的，即使對那些剛接觸機器學習的人來說，整個過程也十分有趣并具有吸引力。創建工作應用程序的低門檻意味著我們將看到更多內置智能決策的邊緣設備。45.GCPVertexAI評估GCP Vertex AI 是一個統

69、一的人工智能平臺，它讓團隊可以構建、部署、并擴縮機器學習（ML）模型。Vertex AI 中包含了可以被直接、微調后、或者結合 AutoML 使用的預訓練模型，也包含了如特征存儲和流水線等機器學習模型的基礎設施。我們喜愛 Vertex AI 的集成能力，這有助于讓它更像一個連貫的人工智能平臺。46.Gradient評估Gradient 是一個用于構建、部署和運行機器學習應用的平臺，它非常類似于谷歌的 Colab。用戶可以從模板創建 Notebook，以快速搭建 PyTorch 或 TensorFlow 或像 Stable Diffusion 這樣的應用。根據我們的經驗，Gradient 非常適

70、合用于構建 GPU 密集型的模型，而且我們喜愛它的 Web 環境能夠持久化保存的特點。47.IAMRolesAnywhere評估IAM Roles Anywhere 是 AWS 的一項新服務，可讓你在 IAM 中為運行在 AWS 之外的服務器、容器和應用程序等工作負載獲取臨時的安全憑證。我們發現它對工作負載分散在 AWS 和非 AWS 資源之間的混合云中特別有用。借助 IAM Roles Anywhere，現在你可以使用 X.509 數字證書創建短期憑證以此來訪問 AWS 資源，而不用創建長期憑證。我們相信這種方法簡化了整個混合云的訪問模式，建議你可以了解看看。48.Keptn評估Keptn

71、是用于交付和運維的控制平臺，它依賴于 CloudEvents 進行插樁。就像我們在 CI/CD 流水線觀測技術中提到的，Keptn 將其編排可視化為 traces。交付流水線旨在將 SRE 意圖與底層實現分離，依靠其他可觀測性、流水線和部署工具來響應適當的事件。我們對 Keptn 將服務級別目標（service-level objective，SLO）驗證作為架構適應度函數添加到 CI/CD 流水線的想法感到特別興奮：Keptn 允許你將服務水平指標（service-level indicators，SLI）定義為鍵值對，它的值表示對觀測性基礎設施的查詢方法。之后，Keptn 將根據定義的平臺

72、24 Thoughtworks,Inc.All Rights Reserved.平臺25SLO 評估結果作為交付質量關口。例如，Keptn 對自動化操作采用相同處理，允許使用聲明式定義來指定擴展ReplicaSet 的意圖，以降低平均響應時間。作為由 Dynatrace 創建的產品，Keptn 還可以與 Prometheus 和Datadog 進行集成。49.OpenMetadata評估毫無疑問，數據的可發現性已變成各個公司重要的關注點，因為它使得不同人群之間的數據共享和使用變成可能，在之前的版本中技術雷達已經包括了 DataHub，Collibra 等平臺，但是我們仍在評估這個領域的其他選項

73、，并且最近我們對 OpenMetadata 產生了興趣。OpenMetadata 是一個致力于使用開放標準進行元數據管理的平臺。我們的團隊喜歡這個開源平臺，因為它簡單的架構、聚焦于自動化的部署、和在數據可發現性的重點關注能提升開發體驗。50.OrioleDB評估OrioleDB 是一個為 PostgreSQL 打造的全新存儲引擎。我們團隊在大量使用 PostgreSQL 的過程中發現，盡管其現有多個選項用來適應現代硬件，但因其存儲引擎最初是為機械硬盤設計，達成優化目標的過程可能困難并且繁瑣。OrioleDB 為了解決這些問題，實現了顯式支持固態硬盤和非易失性隨機存取存儲器（NVRAM）的云原生

74、存儲引擎。想要試用該引擎，用戶首先需要給當前的表訪問方法安裝增強補丁，然后以 PostgreSQL 擴展的形式安裝 OrioleDB。我們相信 OrioleDB 有很大的潛力去解決某些 PostgreSQL 中的長期遺留問題，因此，我們鼓勵你仔細地對該引擎進行評估。Thoughtworks,Inc.All Rights Reserved.工具采納51.Great Expectations52.k6試驗53.Apache Superset54.AWS Backup 文件庫鎖定55.AWS Control Tower56.Clumio Protect57.Cruft58.Excalidraw59.

75、Hadolint60.Kaniko61.Kusto 查詢語言62.Spectral63.Styra Declarative Authorization Service64.監視項目構建的 xbar評估65.Clasp66.Databricks Overwatch67.dbtvault68.git-together69.Harness 云服務成本管理70.Infracost71.Karpenter72.Mizu73.Soda Core74.Teller75.Xcode Cloud暫緩76.在線格式化或代碼解析服務310222315132529414243444546474849503133353

76、436373840151416242617187911202165455566566676869717072737475765759606163648287909293919495969798991021001011038827303239287977788384868589808124819125153586252暫緩暫緩評估評估試驗試驗采納采納新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.51.GreatExpectations采納Great Expectations 已經成為了我們的團隊在數據質量領域的默認選擇，這也是為什么我們建議采納

77、它，不僅僅是因為沒有更好的替代方案，更多的是因為我們的團隊在幾個客戶項目中都報告了它非常好的表現。Great Expectations 作為框架，允許用戶搭建用于標記數據流水線中的異?；蛸|量問題的內置控件。正如單元測試在構建流水線中運行一樣，Great Expectations 在數據流水線的執行過程中進行斷言。我們喜歡它的簡單性和易用性，無需數據工程技能，保存在 JSON 里面的規則都可以被我們的數據領域專家修改。52.k6采納自從我們第一次在技術雷達中提及 k6 以來，它正逐漸成為性能測試的首選工具。我們非常喜歡它。因為它很容易為測試編寫 JavaScript 代碼，此外 k6 也有一個低

78、代碼測試生成器，使它更易于使用。文檔顯示 k6 可以很容易地在多種 CI/CD 流水線中添加性能測試。我們的團隊發現，k6 很容易與可視化工具集成，如 Grafana 和New Relic，這有助于調試基礎設施和應用程序。當需要測試系統在重負荷下的行為時，k6 對開發者友好的特性及其生態系統，讓它成為了不二之選。53.ApacheSuperset試驗Apache Superset 是一個很棒的 BI（Business Intelligence，商業智能）工具，用于與大型數據湖和數據倉庫一起進行數據探索和可視化。它支持多種數據源，包括 AWS Redshift，BigQuery，Azure MS

79、 SQL，Snowflake和 ClickHouse。此外，并非只有數據工程師才可以使用它，所有的工程師在日常工作中探索數據都能夠從中受益。對于高性能需求的用例，我們發現 Superset 易于橫向擴展，因為它被部署在一個 Kubernetes 集群上。自從我們上次在技術雷達中提及它后，Superset 已經從 Apache 孵化器中畢業，并且我們在多個項目中見到了它的巨大成功。54.AWSBackup 文件庫鎖定試驗保證備份在失效前無法被惡意或意外地刪除、修改，在實現穩健、安全且可靠的災難恢復時是十分必要的。在之前使用 AWS Backup 時，這些策略和保證只能通過手動實現。最近，AWS

80、添加了文件庫鎖定這一功能，以確保備份不可變且不可修改。AWS Backup 文件庫鎖定強制應用保留和刪除策略，甚至防止包括擁有管理員權限的用戶修改或刪除備份文件。該功能的加入非常有價值，填補了之前在這一需求上的空白。55.AWSControlTower試驗多團隊的賬戶管理在 AWS 中是一個挑戰，特別是設置和管控方面；AWS Control Tower 試圖解決這一挑戰。據我們團隊的報告，使用它在單一且集中的位置為組織中的多個團隊進行賬戶管理和訪問控制，取得了良好的 效果。工具27 Thoughtworks,Inc.All Rights Reserved.56.ClumioProtect試驗我

81、們成功地用 Clumio Protect 備份了 AWS 數據，特別是針對 S3。作為一個商業 SaaS 解決方案，Clumio Protect 還可以備份一系列其他 AWS 服務，并在無法通過互聯網訪問的地方離線存儲數據。我們負責處理大規模數據保護和恢復的團隊發現 Clumio Protect 很容易設置和維護；當 S3 存儲桶特別大的情況下，其性能遠遠超過原生的 AWS 備份服務。57.Cruft試驗自從我們第一次定義微服務以來，我們就一直在談論定制化服務模板。如果組織著手創建一個可以獨立但一致地開發、構建、部署和操作的微服務集合，那么為團隊提供一個符合標準的堅實起點是有意義的。然而，這種

82、方法一個持久的問題是，隨著時間的推移，模板會隨著技術和業務需求的變化而發展，基于舊版本模板的項目就會過時了。改造模版從而改進已建立的項目成為一個重大的痛點。Cruft 試圖通過提供工具來解決這個問題，以識別和修補本地項目與主模板庫的當前版本之間的差異。它將 Cookiecutter 模板引擎與 git 哈希值相結合，以識別和應用模板的變化?？梢园阉醋魇琼椖磕０宓囊粋€包管理器。保持模板的更新是一個眾所周知并長期存在的難題，因此對我們來說，Cruft 提供的解決方案聽起來好得令人難以置信。然而，根據我們團隊先前的反饋，Cruft 確實是有效的，并使服務構建者和維護者的工作更輕松。我們急切地想看看

83、它的長期表現如何，但現在這個可能有用的工具也值得嘗試。58.Excalidraw試驗我們不斷地從我們的團隊中聽到關于 Excalidraw 的熱心報告，但我們先前關于安全的警告仍然存在。Excalidraw 是一個簡單卻強大的在線繪圖工具。有些時候團隊只是需要一張快速的圖片而不是正式的圖表；對于遠程團隊而言，Excalidraw 提供了一種快速創建和分享圖表的方式。我們的團隊還喜歡它可以產出低保真樣式的圖表，這讓人想起他們在同地協作時繪制的白板圖表。至于安全性，在撰寫本文時，任何擁有鏈接的人都可以查看您的圖表；但請注意，付費版 Excalidraw 提供了進一步的身份驗證功能并且擁有部署本地化

84、服務器的選項。59.Hadolint試驗我們樂于傳播有關代碼靜態檢查工具的訊息，這些工具實際上可以幫助您發現問題而不僅僅是處理團隊中縮寫風格的爭議。Hadolint 是一個這樣的工具，它有助于發現 Dockerfile 中的常見問題。我們發現它可以快速、準確地發現問題且具有良好的使用文檔。它會在第一時間解釋如何解決問題以及為什么它是一個問題，從而促使Dockerfile 作者趨向好的實踐。順便一提，Hadolint 是基于我們推薦使用于檢查 shell 腳本的 ShellCheck 工具構建的。工具28 Thoughtworks,Inc.All Rights Reserved.60.Kanik

85、o試驗當前大多數的 CI/CD 流水線工具和平臺都是以容器作為運行時構建的。而我們的許多團隊正在使用 Kaniko 從這些基于容器的流水線中構建容器鏡像。這是一種趨勢的一部分，即不再將 Docker 容器運行時作為業界標準。有了 Kaniko，您可以在不使用 Docker 守護進程的情況下構建鏡像。這有助于避免 Docker“特權”模式所帶來的安全問題，而“特權”模式對任何“在 Docker 中運行 Docker”的活動都是必要的。此外，您不必首先確保流水線可以訪問 Docker 守護進程。通常這都需要額外的配置，而現在都不再是理所當然。61.Kusto 查詢語言試驗當數據相關工作變得越來越常

86、見，我們不斷見到嘗試對 SQL 語言進行改進的工具；Kusto 查詢語言（KQL）是其中的一種。KQL 是由 Azure 創建的語言，它給關系型查詢語言帶來了模塊、封裝、組合、復用、擴展、和動態化的能力。我們的團隊格外喜歡它的交互性：你可以將一個查詢語句導入渲染操作符并立刻看到生成的圖表。你也可以組合這些圖表到儀表盤上，同時從分鐘級的運行日志上獲得洞見。盡管KQL目前只能在Azure Data Explorer中使用，我們預計對 SQL 進行改進以實現更好的數據操作性的步伐不會停止。62.Spectral試驗Spectral 是一個強調 OpenAPI 和 AsyncAPI 的 JSON/YA

87、ML 代碼靜態檢查工具（linter）。在設計和實現 API 或進行事件驅動的協作時，它所提供的全面且開箱即用的規則可以幫助開發者省去很多麻煩。這些規則可以用于檢查 API 參數規范或規范中存在的許可聲明等。其 CLI 能夠讓本地開發和 CI/CD 流水線中更容易地引入 Spectral，而 JavaScript API 則支持更高級的使用場景。它的 GitHub 頁面鏈接了一些公開的真實公司（比如 Adidas）正在使用的規則集，這使得團隊在采用他們自己的檢查規則時有了一個良好的開始。63.StyraDeclarativeAuthorizationService試驗Styra Declara

88、tive Authorization Service（DAS 聲明式授權服務）是一個用來規?；芾?Open Policy Agent（OPA）的治理和自動化工具。該工具由 OPA 的開發者建立，它允許我們在不同“系統”中部署策略，包括 Kubernetes 集群、基礎設施代碼倉庫、命名空間以及其他。最重要的是，它能對 OPA agent 做出的決定進行實時分析，以及具有調試和調查假設性策略變更場景的回放能力。它還帶有審計日志，可以幫助安全團隊進行歷史報告。64.監視項目構建的 xbar試驗在遠程團隊中，我們非常缺乏一個專用的項目構建監視器；不幸的是，新興的持續集成（CI）工具缺乏對舊CCTr

89、ay 格式的支持。其結果是，失敗的構建并不能及時地被團隊發現。為了解決這個問題，我們的許多團隊已經開始使用監視項目構建的 xbar。xbar 可以執行腳本來輪詢構建狀態，并將其顯示在電腦的菜單欄上。也可工具29 Thoughtworks,Inc.All Rights Reserved.工具以編寫復雜腳本來跟蹤其他團隊指標，例如檢查憑證到期，或生產版本落后于用戶驗收測試（UAT）版本的差距等。當然，xbar 的功能遠不止這些，但它解決了遠程工作中直接和緊急的問題。Rumps 等工具同樣也可以解決這些問題。65.Clasp評估不幸的是，電子表格（spreadsheet）在這個世界依然大行其道，而且

90、在可見的未來也仍會如此。電子表格是人們構建符合他們特定需求的自定義小工具的終極武器。然而，當你試圖使用一些需要“真正的”代碼邏輯來增強這些小工具的時候，電子表格的低代碼屬性就會變得非常有局限性。如果你在一個類似 Thoughtworks 這樣使用 Google 的 G-Suite 的公司，Clasp 使你至少可以在 Apps Script 代碼里應用一些 Continuous Delivery 的實踐。它可以讓你在 Apps Script 項目之外編寫代碼，這樣就有了測試、版本控制和構建流水線，甚至使用TypeScript 的可能性。Clasp 已經存在一段時間了，你不應期待它提供一個常規的舒

91、適編程環境，但它確實能極大地提升使用 Apps Script 的體驗。66.DatabricksOverwatch評估Databricks Overwatch 是 Databricks 實驗室的項目，它讓團隊能分析 Databricks 負載運行時的各種包括成本、治理、和性能在內的多種運營指標，并且支持運行假設性的試驗。它本質上是一系列在 Databricks 中填充數據表格的數據流水線，這使得它可以被例如計算筆記本（Notebooks）這類工具分析。Overwatch 是一個非常強大的工具，但仍處于試驗階段，并且它需要一定的時間成本進行配置。在使用中我們發現，Overwatch 需要 Dat

92、abricks 解決方案架構師幫助建立并填充一個用于成本計算的價格參考表，但是我們預計使用它會變得日益輕松。Overwatch 提供了相對于云提供商的成本分析工具進行更深入分析的可能性。例如，我們能分析任務失敗的成本（認識到快速失敗比在接近最后一步時才失敗的任務更省錢），并且將成本劃分為各種組別（工作區，集群，任務，計算筆記本，團隊）。我們也喜歡它提高的操作可見性，這使得我們可以輕松審計集群設置的訪問控制并分析運營指標，例如找到長時間工作的計算筆記本或者是最大的讀寫卷。Overwatch 可以分析歷史數據，但它的實時數據也允許設置警報，這能幫助你對 Databricks 負載添加合適的控制。6

93、7.dbtvault評估Data Vault 2.0 是一種數據建模方法和設計模式，相對于其他流行的建模方法，它的目的是進一步提高數據倉庫的靈活性。Data Vault 2.0 可以應用于任何數據存儲中，例如 Snowflake 或 Databricks。當實現 Data Vault倉庫時，我們發現 dbt 的 dbtvault 包是一個有用的工具。dbtvault 提供了一組 jinja 模版，用于生成和執行填充 Data Vault 倉庫所需的 ETL 腳本。盡管 dbtvault 存在一些小缺陷，如它缺乏對強制隱含惟一性和增量加載的支持。但總的來說，它填充了市場空白并且只需最小配置即可開

94、始使用。30 Thoughtworks,Inc.All Rights Reserved.68.git-together評估我們對于 git-together 的出現感到十分激動，因為我們一直在消除由結對編程帶來的不便。git-together 使用 Rust 編寫，簡化了結對編程時代碼提交的屬性配置。通過將 git-together 設置為 git 的別名，git-together 允許您在 git config 中添加擴展配置以捕獲提交者的信息，并以每個提交者的首字母為別名。更改結對對象或者切換到單人編程或暴徒式編程（Mob Programming）時，需要您運行 git with 命令，并

95、以pair 對象名稱的首字母收尾（例如：git with bb cc），這將便于您此后恢復到常規的 git 工作流。每次提交時，git-together 都會在 git 存儲的結對對象信息中輪換作者身份，并且它會自動將任何其他作者添加到提交消息的底部。相關的配置可以和代碼倉庫一起 check in，從而使 git-together 可以在克隆代碼倉庫后自動生效。69.Harness 云服務成本管理評估Harness 云服務成本管理是一款為三個主要的云服務提供商及其托管的 Kubernetes 集群提供服務的商業工具，用來幫助其可視化及管理云服務成本。該產品通過查看空閑資源以及未分配給任何工作負

96、載的資源來計算成本效率分數，并使用歷史變化趨勢來幫助其優化資源分配。儀表盤突出顯示成本峰值，并允許用戶注冊未按照預期發生的意外現象，然后為他們圍繞異常檢測的強化學習算法提供素材。云成本管理可以提供調整內存和 CPU使用限制的建議，并提供優化成本或性能的選項?！癙erspectives”允許您根據按照組織結構定義的過濾器（可能對應于業務部門、團隊或產品）對成本進行分組，并自動分發報告以可視化云服務支出。我們相信 Harness云服務成本管理提供了一個有說服力的功能集，來幫助組織使他們的 FinOps 實踐變得更加成熟。70.Infracost評估我們不斷地看到有企業在沒有恰當理解如何持續監控云上

97、運營成本的時候向云服務遷移。我們之前提過將運行成本實現為架構適應度函數，而 Infracost 是一個旨在在 Terraform pull request 中可視化成本權衡的工具。它是一個開源軟件，在 macOS、Linux、Windows 和 Docker 均可訪問，開箱即用支持 AWS、GCP 和微軟 Azure 的定價。它還提供了一個公共 API，可以查詢到當前的成本數據。我們仍然對它的潛力感到興奮，特別是它還將支持在 IDE 中提供更好的成本可見性。71.Karpenter評估Kubernetes 的基本功能之一是它能夠在需要額外生產力時自動啟動新的 Pod，并在負載減少時關閉它們。這

98、種水平自動縮放是一個有用的功能，但它只有在需要托管 Pod 的節點已經存在時才能工作。雖然Cluster Autoscaler 可以做一些由 pod 故障觸發的基本集群擴展，但它的靈活性有限；不過我們發現了另一個開源的 Kubernetes Operator 自動擴縮器 Karpenter，它內建了更多智能：可以分析當前的工作負載和 Pod調度約束，以自動選擇合適的實例類型，然后根據需要啟動或停止它。Karpenter 是一個具有如 Crossplane等工具精神的 operator，可以在集群外提供云資源。Karpenter 是云供應商通過其托管的 Kubernetes 集群原生提供的自動縮

99、放服務的一個極具吸引力的工具。例如，AWS 現在在其 EKS Cluster Autoscaler 服務中支持將Karpenter 作為首選的替代方案。工具31 Thoughtworks,Inc.All Rights Reserved.72.Mizu評估Mizu 是一個 Kubernetes 的 API 流量查看器。與其他工具不同的是，Mizu 不需要增加監測工具或改動代碼，而是在 Kubernetes 集群的節點層面上注入一個容器作為 DaemonSet，做一些類似 tcpdump 的操作。我們發現Mizu 可以實時監測多種協議（REST、gRPC、Kafka、AMQP 和 Redis）下的

100、所有 API 通信，因此它可以作為一個調試工具來使用。73.SodaCore評估Soda Core 是一個開源數據質量與可觀測性工具。我們在之前的技術雷達上討論過 Great Expectations，而Soda Core 作為另一種解決方案，其關鍵區別在于數據校驗可以通過一種稱為 SodaCL（之前稱為 Soda SQL）的 DSL 來表示，而非 Python 函數。數據校驗一旦被寫好就可以作為數據流水線的一部分被執行，也可以通過編程方式調度運行。隨著我們越來越多地受數據驅動，數據質量的維護變得至關重要，因此我們建議你評估 Soda Core。74.Teller評估Teller 是一款面向開

101、發人員的開源通用密鑰管理器，可確保應用程序啟動時，環境變量可以被正確地配置。然而，它本身并非一個存放私密信息的保險庫（vault），而是一個可連接多種源的 CLI 工具，從云密鑰提供者到諸如 HashiCorp Vault 的第三方解決方案再到本地環境文件。Teller 還具有如下的額外功能：掃描代碼中保存在 vault 中的密鑰、編輯日志中的密鑰、檢測各密鑰提供者之間的變化并進行同步。鑒于訪問密鑰訪問行為的敏感性，無論如何強調對開源依賴供應鏈安全保障的必要性都不為過，但我們依然欣賞 Teller 作為一款 CLI 工具在本地開發環境、CI/CD 流水線和部署自動化中的使用便捷性。75.Xco

102、deCloud評估Xcode Cloud 是一個集成在 Xcode 中的 CI/CD 工具，用于開發、測試和部署蘋果應用程序。它為熟悉 Xcode、App Store Connect 和 Test Flight 的蘋果開發人員提供了一體化的體驗。根據我們團隊的經驗，它的優勢在于簡化流水線配置和創建配置文件和證書。這個工具面世不久，我們大多數的移動端開發團隊仍然在使用更為成熟的 Bitrise。盡管如此，它仍然值得我們去評估和追蹤它的發展。76.在線格式化或代碼解析服務暫緩我們之前提到了測試環境中的生產數據，現在想強調另一個需要小心處理甚至完全停止的常見實踐：在線格式化代碼解析服務。有許多有用的

103、網站提供格式化或解析格式（如 JSON 和 YAML）的服務，還有許多評估代碼教程或在線生成代碼衡量指標的網站。使用這些產品時需要非常小心。將 JavaScript、JSON 或類似代碼片段粘貼到一個未知的網站很容易造成安全和隱私問題，并可能在不知不覺中將個人數據導出到不同的信息管轄區。這些站點不應該與生產數據一起使用，并且在任何其他情況下都應該謹慎對待。工具32 Thoughtworks,Inc.All Rights Reserved.語言和框架采納77.io-ts78.Kotest79.NestJS80.React Query81.Swift Package Manager82.Yjs試驗

104、83.Azure Bicep84.Camunda85.Gradle Kotlin DSL86.Jetpack Media387.Ladle88.Moshi89.Svelte評估90.Aleph.js91.Astro92.BentoML93.Carbon Aware SDK94.Cloudscape95.Connect96.跨設備 SDK97.Cypress 組件測試98.JobRunr99.Million100.Soketi101.Stable Diffusion102.合成數據保險庫暫緩103.Carbon3102223151325294142434445464748495031333534

105、36373840151416242617187911202165455566566676869717072737475765759606163648287909293919495969798991021001011038827303239287977788384868589808124819125153586252暫緩暫緩評估評估試驗試驗采納采納新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.77.io-ts采納我們使用 TypeScript 開發的團隊發現 io-ts 非常有價值，特別是在與最終導致創建具有特定類型的對象的 API交互時。在使

106、用 TypeScript 時，將數據輸入到類型系統的范圍內（比如來自上述 API）可能會導致運行時錯誤，而這些錯誤可能很難發現和調試。io-ts 通過提供編碼和解碼函數，在編譯時類型檢查和運行時消耗外部數據之間架起橋梁。鑒于我們團隊的經驗和其方法的優雅性，我們認為 io-ts 值得采納。78.Kotest采納Kotest（原名 KotlinTest）是 Kotlin 生態中的一個獨立測試工具，它在我們的團隊各式各樣的 Kotlin 實現（原生、JVM 或 JavaScript）中越來越受到關注。Kotest 的主要優點是它提供了豐富的測試風格來搭建測試套件，其中還有一套全面的匹配器，可以幫助你

107、使用優雅的內部領域專用語言（DSL）編寫表達式測試用例。Kotest除了支持基于屬性的測試之外，我們團隊也看好它可靠的 IntelliJ 插件和支持社區。我們的許多開發者將它列為首選并推薦那些仍在 Kotlin 中使用 JUnit 的開發者考慮切換到 Kotest。79.NestJS采納過去，我們警告過 Node 泛濫的問題，即使現在，在選擇 Node 時，我們仍然持謹慎態度。然而，據我們團隊報告，在需要使用 Node.js 構建后端應用程序的某些場景下，NestJS 是一個很好的選擇。它使開發人員能夠創建可測試、可擴展、松耦合且易于維護的企業級應用程序。NestJS 是一個 TypeScri

108、pt 優先的框架，它使 Node.js 應用程序的開發更安全，更不容易出錯。NestJS 采用了面向對象的編程思想，遵循 SOLID 原則，同時受到Angular 啟發，采用了開箱即用的架構。80.ReactQuery采納React Query 通常被描述為 React 缺失的數據獲取庫。獲取，緩存，同步和更新服務器狀態是許多 React 應用程序常見的需求，盡管這些需求易于理解，但眾所周知，正確地實現這些需求非常困難。React Query 提供了一種基于 hooks 的更直接的方式。它與現有的基于 promise 機制的異步數據獲取庫協同工作，如 axios、Fetch和 GraphQL。

109、作為應用程序開發人員，你只需要傳遞一個解析數據的函數，其余的事情可以留給框架完成。該工具開箱即用，但也可以按需進行配置。它的開發者工具也能幫助剛接觸此框架的開發人員理解其工作原理，遺憾的是，其開發者工具尚不支持 React Native。對于 React Native，你可以使用第三方開發者工具插件 Flipper?；谖覀兊慕涷?，React Query 的第三版為我們的客戶提供了生產環境所需的穩定性。81.SwiftPackageManager采納當 Swift 在 2014 年推出時，并沒有發布相應的包管理器。后來，Swift Package Manager 作為蘋果官方開源項目創建，該項

110、目在之后的時間中不斷發展和成熟?，F如今，我們的團隊越來越依賴 SwiftPM，因為大多數的語言和框架34 Thoughtworks,Inc.All Rights Reserved.依賴包都可以通過它進行管理，并且通過 SwiftPM，依賴包的創建者和使用者的操作流程都得到了極大的簡化。在之前的技術雷達中，我們建議大家可以嘗試使用該項目進行包管理，但如今，我們認為應該在啟動新項目時將其作為首選。對于那些使用 CocoaPods 或 Carthage 等工具的現有項目，進行一個快速試驗，來衡量遷移的難易程度，并檢查所有依賴項是否都可用是值得的。82.Yjs采納無沖突復制數據類型（CRDT）算法被證

111、明能夠在對等節點中自動地分發與合并修改而不產生沖突。但是在實踐中，即使對于足夠小的數據，這些算法通常也需要大量內存來追蹤由不同對等節點做出的所有修改，從而變得不切實際。Yjs 是一個精心優化的 CRDT 實現，能夠在面對大型數據集和數百萬個修改時將內存開銷保持在合理的水平。它也能綁定到流行的文本編輯器上，這一點顯著地降低了構建協作工具的成本。83.AzureBicep試驗Azure Bicep是一種使用聲明式語法的領域特定語言（DSL），主要面向那些喜歡使用比JSON更自然的語言來編寫基礎設施代碼的人。它支持可重用參數化模板來實現模塊化資源定義。它有 Visual Studio Code ex

112、tension插件為其提供實時類型安全、智能感知和語法檢查的功能，并且它的編譯器允許雙向轉換 Azure Resource Manager（ARM）模板。Bicep 面向資源的 DSL 以及與 Azure 生態系統的原生集成使其成為 Azure 基礎設施開發人員的不二之選。84.Camunda試驗自從我們上次提到 Camunda 以來，我們已經看到了我們的許多團隊和客戶在使用該平臺，使其在適合引入工作流引擎的領域里，成為我們的首選工作流引擎之一。Camunda 提供的工作流和決策引擎可以作為庫集成到用戶的 Java 代碼中。這使得測試、版本化和重構工作流變得更容易，緩解了其他低代碼工作流引擎的

113、一些缺點。我們甚至已經看到Camunda在具有高性能要求的環境中被使用。一些團隊還很喜歡它可以很容易與Spring Boot做集成及它漂亮的用戶界面。85.GradleKotlinDSL試驗之前，我們介紹過 Android Gradle 插件 Kotlin DSL，或 Gradle Kotlin DSL，它為使用 Gradle 構建腳本的Android 工程增加了對 Kotlin 腳本的支持，以替代 Groovy。用 Kotlin 替換 Groovy 的目的是在 IDE 中為重構與更簡便地編輯提供更好的支持，以及最終產出更易于閱讀和維護的代碼。對已經正在使用 Kotlin 的團隊而言，這也意味

114、著使用一門熟悉的語言處理構建。一般來說，我們現在建議在 Gradle 工程中試用 Kotlin DSL 作為Groovy 的替代語言，尤其是當您有龐大或復雜的 Gradle 構建腳本時。許多 IDE 現在都支持遷移現有工程。仍然存在一些警告，我們建議檢查文檔以獲取包括前置條件在內的最新細節。我們有一個團隊把至少有七年歷史的、450 行的構建腳本在幾天之內成功地遷移了。語言和框架35 Thoughtworks,Inc.All Rights Reserved.86.JetpackMedia3試驗現如今安卓擁有多個媒體 API：Jetpack Media（也被稱為 MediaCompat），Jetp

115、ack Media2 和 ExoPlayer。然而，這些庫都是分別開發的，它們的目的不同但是功能重疊。這就導致安卓開發者在編碼的時候不僅需要斟酌類庫的選型，當使用的特性來自于多個庫的時候，還需要編寫適配器或者兼容代碼。Jetpack Media3 是從現有 API 中選取通用的功能：包括 UI、播放和媒體會話處理，然后將它們合并和改進成一個新的 API。ExoPlayer的播放器界面也進行了更新、增強和簡化，被用作 Media3 的通用播放器界面。在早期訪問階段之后，Media3目前仍處于早期開發版本。雖然它的第一個正式版本即將發布，但我們已經在應用程序中使用 Media3 得到了積極的體驗。

116、87.Ladle試驗隨著 Storybook 變得受歡迎，它變得越來越像一個龐然大物。如果你真正關心的是隔離和測試你的 React UI組件，那么 Ladle 是一個替代品。Ladle 支持大多數的 Storybook API（MDX 文件暫時不支持），且可以作為Storybook 的替代品。它是輕量級的，與 Vite 有更好的集成。并且它還提供了簡單整潔的能輕易地與其他測試框架集成的 APIs。88.Moshi試驗聽說很多使用Kotlin語言的團隊在尋找可以替代GSON這樣基于Java的JSON處理工具。剛出現不久的Moshi已經成為了許多此類團隊的首選方案。從 GSON 遷移到 Moshi

117、 非常簡單，且后者原生支持 Kotlin 語言中的非空類型和默認參數特性，使得處理 JSON 的工作變得更加高效便捷。如果你正在 Kotlin 中使用基于 Java 的 JSON處理工具，我們建議你嘗試一下 Moshi。89.Svelte試驗在 Web 組件框架中，Svelte 通過將反應性從瀏覽器中轉移到編譯器中而脫穎而出。Svelte 不是通過使用虛擬DOM 和瀏覽器優化技巧來優化 DOM 更新，而是將你的代碼編譯成無框架的 JavaScript 代碼，像做外科手術一樣更新 DOM。除了運行時的性能優勢之外，這也讓 Svelte 在不犧牲開發者功能的情況下優化瀏覽器必須下載的代碼量；此外，

118、事實證明，由于在瀏覽器中執行的代碼較少，它對移動網絡應用的性能和電池需求更加友好。除了性能優勢之外，我們團隊還欣賞它友好的學習曲線和來自于編寫更少代碼的維護優勢。Svelte 本身只是組件框架，但 SvelteKit 增加了可以構建完整 Web 應用程序的功能。90.Aleph.js評估目前并不缺少通過 JavaScript/TypeScript 去創建網絡應用的架構。我們在技術雷達中已經介紹了很多種，但真正讓 Aleph.js 從中脫穎而出的是它最初就是建立在 Deno 上的?？紤]到 Deno 是由 Node 原本的開發者所創建的新的服務器端運行時，這意味著 Aleph.js 處在一個更先進

119、的平臺上，能夠解決 Node 相關的很多缺陷和問語言和框架36 Thoughtworks,Inc.All Rights Reserved.題。雖然 Aleph.js 很新，至截稿時仍然在準備 1.0 版本的發布，但它已經能夠為我們提供穩定的開發體驗，包括組件的熱插拔等。鑒于 Deno 早已完成 1.0 的發布，對于那些能夠承擔風險的項目來說，Aleph.js 無疑是一個現代化的選擇。91.Astro評估令人難以置信的是，即使到了 2022 年，開發者社區仍在持續推出有趣的，用于構建 web 應用程序的新框架，Astro 就是最新推出的開源，多頁面響應的應用程序框架，它可以在服務器上渲染頁面并盡

120、可能減少通過網絡發送的 JavaScript 數量。Astro 看起來非常適合那些從多種渠道獲取資源的內容型網站。我們喜歡 Astro 的一點是，盡管 Astro 鼓勵只發送 HTML，但它仍然支持在適當的時候選擇用您選用的前端 JavaScript 框架編寫的活動組件。它通過 island architecture 做到這一點。島嶼是單個頁面中的交互區域，僅在需要時才下載必要的JavaScript。Astro 是相對較新的技術并且看起來支持日益增加的開發者及代碼生態系統。它的發展值得關注。92.BentoML評估BentoML 是一個 Python 優先的框架，用于在生產環境中規?；渴饳C器

121、學習模型。它提供的模型與環境無關；所有模型屬性、源代碼和依賴包都封裝在稱為 Bento 的自包含格式中。這就像“模型即服務”一樣。您可以將 BentoML 視為機器學習模型的 Docker：它使用預編程 API 生成可立即部署的虛擬機鏡像并包含相應的功能使測試這些映像變得十分簡單。BentoML 可以通過簡化項目初始階段的任務加速項目的開發，這是我們將其歸納在評估環中的原因。93.CarbonAwareSDK評估當我們著眼于減少一款應用程序的碳足跡（運行軟件間接導致的二氧化碳排放）時，注意力通常被導向讓軟件更加高效上。思路很明確：更高效的軟件只需要更少的電力和服務器，從而減少發電與制造服務器所

122、帶來的碳排放。另一個策略是使應用程序具有碳意識。這是因為同樣的工作負載并不總是具有相同的碳足跡。例如：在較冷氣候的數據中心運行時，用于空調的電力需求會減少；或者，在能夠使用更多的可再生能源（更多的陽光，更強的風力）時，碳基來源的電力需求會減少。借助 Carbon Aware SDK，軟件工程師們可以查詢數據源來發現對于給定的工作負載而言碳密集度更低的選項，然后將它移動到不同的位置或是在不同的時間運行它。這對那些對于時間和延遲都不敏感的大型工作負載來說是有意義的，例如訓練機器學習模型。雖然這個 SDK 和可獲取的數據源還不是很全面，但是我們相信是時候開始探索如何能讓我們的系統具有碳意識了。94.

123、Cloudscape評估Cloudscape 是一款開源的設計系統，它不僅有一套豐富的組件集，還有 35 種交互和內容展示模式。與此同時，它使用設計令牌來進行主題化，并提供元素包裝器給所有組件，這極大地簡化了單元測試。這幾點讓它從眾多設計系統中脫穎而出。語言和框架37 Thoughtworks,Inc.All Rights Reserved.95.Connect評估Connect 是一系列用于構建與瀏覽器和 gRPC 兼容的 HTTP API 的庫。與 gRPC 類似，您編寫協議緩沖區的架構并實現其應用程序邏輯，然后 Connect 生成代碼來處理編組、路由、壓縮和內容類型協商。但是，Conn

124、ect嘗試以多種方式去改進 gRPC。包括在沒有翻譯代理的情況下對 gRPC-Web 的原生支持；與第三方路由器或中間件的互操作性，因為 connect-go 構建在 net/http 之上（與 grpc-go 不同）；以及完全生成的類型安全的，具有手工代碼的人體工程學的客戶端。我們大多更喜歡 REST，而不喜歡使用 RPC 方法去構建 API。也就是說，Connect 似乎解決了我們對 RPC 的一些擔憂，我們鼓勵您對其進行嘗試。96.跨設備 SDK評估隨著智能設備持續融入我們的生活，我們開始看到跨越多個設備的新用例出現。典型的例子是我們在手機上開始閱讀一則文本但是更喜歡在平板電腦上讀完它。

125、其它例子包括在筆記本電腦上繪制騎行路線，然后把數據傳輸到自行車電腦上以便于導航，或是使用移動手機作為網絡攝像頭。這些使用場景需要非常特定類型的功能，例如發現附近設備、安全通信以及多設備會話。Apple 不久前已經開始將此類功能引入到它自己的 SDK 中了，現在 Google 也發布了其跨設備 SDK 的首個預覽版本。盡管該預覽版本有一些限制例如，僅支持手機與平板，并且一次僅支持兩個設備，但是這項技術還是令人興奮，在其推出后我們可以隨著時間的推移而采用它。97.Cypress 組件測試評估Cypress 組件測試提供了一個組件測試工作臺，以快速構建和測試 UI 組件。你可以用編寫端到端（E2E）

126、UI 測試的相同 API 來編寫組件視覺回歸測試。盡管仍處于測試階段，但組件測試將成為 Cypress 第十版中最重要的功能。98.JobRunr評估JobRunr 是一個可以替代 Quartz 調度器的 Java 后臺任務執行庫。它內置的用于監控和調度后臺任務的儀表盤操作簡便，深受我們團隊喜愛。JobRunr 是開源且免費商用的，但任務遷移和恢復等功能需要付費使用。99.Million評估Million 是一個新的虛擬 DOM JS 庫。與 Svelte 類似，它使用編譯器 Vite，來創建具有卓越渲染性能的小型JS 庫。Million 庫作為單個 NPM 包提供，其中包含了多個模塊，包括

127、router，jsx-runtime 和一個用于保證React 兼容性的模塊以創建單頁應用程序。盡管 React 在十年前就普及了虛擬 DOM，但在這個領域看到新的創新還是很吸引人的。語言和框架38 Thoughtworks,Inc.All Rights Reserved.100.Soketi評估Soketi 是一個開源的 WebSockets 服務器。如果你的應用程序兼容 Pusher 協議，你可以直接接入 Soketi，因為它完全遵循了 Pusher 協議版本 7。我們發現由 Cloudflare Workers 提供的 beta 支持非常有趣，因為它打開了在網絡邊緣使用 WebSocke

128、ts 的大門。101.StableDiffusion評估OpenAI 的 DALLE 可以從文本提示創建圖像，這吸引了所有人的注意?，F在，Stable Diffusion 也可以提供相同的功能。更重要的是，它是開源的。任何可以使用性能強勁的顯卡的人都可以對模型進行試驗，而任何擁有夠足夠計算資源的人都可以自己重新創建模型。結果很震撼，但也帶來了重大的問題。例如，該模型使用互聯網爬蟲獲得的圖像文本對進行訓練，因此它帶有社會偏見，這意味著它可能會產生非法、令人不安，或至少不受歡迎的內容。雖然 Stable Diffusion 現在有基于 AI 的安全分類器，但由于它是開源的，使用者可以禁用這一分類器

129、。還有，藝術家們注意到，在特定的提示詞下，模型可以模仿他們的藝術風格。因此引發了對于能夠模仿藝術家的人工智能的倫理和法律影響的疑問。102.合成數據保險庫評估合成數據保險庫是一個數據生成工具庫，它可以學習數據集的分布，以生成與源數據具有相同格式和統計屬性的合成數據。在往期的技術雷達中，我們討論過下游應用測試環境中的生產數據。然而，生產環境中數據分布的細微差別很難手工復制，這會導致合成數據中的一些缺陷和無法預知的情況。我們相信合成數據保險庫和類似的工具可以通過合成類生產環境的單表，復合多表和多變量時間序列來填補這個差距。雖然合成數據保險庫并非新鮮事物，我們仍然非?？春眠@項技術并推薦它。103.C

130、arbon暫緩我們看到了一些對 Carbon 編程語言產生的興趣。這一點也不令人驚訝：它有 Google 的背書，而且它被展現為 C+的天生繼承者。在我們看來，C+不會以足夠快的速度被取代，正如在過去幾十年的時間里軟件工程師們所表現的那樣，寫出安全且沒有錯誤的 C+代碼是一件極其困難且耗時的事情。雖然 Carbon 是一個有意思的概念，它專注于從 C+移植，但是在沒有一個可工作的編譯器的情況下，很明顯它離可以使用還有很長的路要走，而且如果你想從 C+移植，也有其他現代的編程語言可以作為不錯的選擇?，F在談 Carbon 是否會成為C+的天生繼承者還太早了，不過，以今天的視角來看，我們推薦項目組去關注一下 Rust 和 Go 而不是等著Carbon 的到來而推遲移植項目。語言和框架39