《Thoughtworks：2024技術雷達-針對當今科技領域發展的前沿指南（第30期）（40頁）.pdf》由會員分享，可在線閱讀，更多相關《Thoughtworks：2024技術雷達-針對當今科技領域發展的前沿指南（第30期）（40頁）.pdf（40頁珍藏版）》請在三個皮匠報告上搜索。

1、 Thoughtworks,Inc.All Rights Reserved.1針對當今科技領域發展的 前沿指南技術雷達2024年4月Volume30 Thoughtworks,Inc.All Rights Reserved.2關于技術雷達 3雷達一覽 4貢獻者 5本期主題 6本期雷達 8技術 11平臺 17工具 24語言和框架 34 Thoughtworks,Inc.All Rights Reserved.3Thoughtworks 技術雷達關于技術雷達Thoughtworker 酷愛技術。我們致力于建造技術，研究技術，測試技術，開源技術，書寫技術，并不斷改進技術。支持卓越軟件并掀起 IT 革

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

3、態度。想要了解更多技術雷達相關信息，請點擊： Thoughtworks,Inc.All Rights Reserved.4技術雷達是具有前瞻性的。為了給新的技術條目騰出空間，我們挪出了近期沒有發生太多變化的技術條目，但略去某項技術并不表示我們不再關心它。暫緩評估試驗采納采納：我們強烈主張業界采用這些技術。我們會在適當時候將其用于我們的項目。試驗：值得追求。重要的是理解如何建立這種能力，企業應該在風險可控的項目中嘗試此技術。評估：為了確認它將如何影響你所在的企業，值得作一番探究。暫緩：謹慎推行。新的挪進/挪出沒有變化雷達一覽技術雷達持續追蹤有趣的技術是如何發展的，我們將其稱之為條目。在技術雷達中

4、，我們使用象限和環對其進行分類，不同象限代表不同種類的技術，而圓環則代表我們對它作出的成熟度評估。軟件領域瞬息萬變，我們追蹤的技術條目也如此，因此您會發現它們在雷達中的位置也會改變。Thoughtworks 技術雷達 Thoughtworks,Inc.All Rights Reserved.5貢獻者技術顧問委員會（TAB）由 Thoughtworks 的 22 名高級技術專家組成。TAB 每年召開兩次面對面會議，每兩周召開一次視頻會議。其主要職責是為 Thoughtworks 的首席技術官 Rachel Laycock 和名譽首席技術官 Rebecca Parsons 提供咨詢建議。作為一個綜

5、合型組織，TAB 能夠審視影響 Thoughtworks 技術戰略和技術人員的各種主題。本期技術雷達內容基于 2024 年 2 月技術委員會成員在紐約的面對面會議創建。Rebecca Parsons（CTO Emerita）Camilla Falconi CrispimJames LewisScott ShawRachel Laycock（CTO）Martin Fowler（Chief Scientist）Erik DrnenburgMarisa HoenigSelvakumar NatesanShangqi LiuSofia TaniaVanya SethWill AmaralBharani

6、 SubramaniamFausto de la TorreMike MasonMaya OrmazaBirgitta BckelerHao XuNeal FordPawan ShahBrandon Byars Thoughtworks,Inc.All Rights Reserved.6（或許）開源的許可證在我們的會議中，關于許可證引發了兩類討論。首先，多年來，開源軟件開發生態系統依賴于一組由開源倡議組織（Open Source Initiative，OSI）編錄的許可證，大多數情況下僅使用流行的幾種。然而，最近發生了一些變化。一些知名工具，最近因為其維護者突然從開源模式切換到商業模式而受到了

7、一些負面評價。當然，我們愿意為軟件付費，并且認可對于額外功能使用商業許可證的常見模式。只是我們覺得，當這種轉變出現在一個受眾廣泛的工具的核心功能上，尤其是當一個生態系統已經圍繞該工具發展起來時，這是有問題的。其次，另一個有趣的轉變出現在一些自詡開源的軟件上，其基本功能只有在消費者支付訂閱費或其他費用后才能使用。盡管這種商業模式以前就存在，但似乎在許多閃亮的新 AI 工具中被更多地利用了它們提供了一些在細則之下過于隱藏的驚人功能。我們建議特別關注許可證問題。在使用中要提起警惕，并確保存儲庫中的所有文件都受到頂層許可證的覆蓋。人工智能助力軟件開發團隊顯然，人工智能目前正在討論中占主導地位：技術雷達

8、中約有三分之一的類目與之相關。我們不僅討論了面向開發者的人工智能工具，如 GitHub Copilot，CodiumAI，aider 和 Continue，我們還探討了如何在整個團隊中全面使用 AI、以及如何利用人工智能改變軟件開發的各個方面。這其中包括一系列最終未能入選的工具，例如Warp 這樣的人工智能輔助終端，將截圖轉換為代碼的能力、由 LLMs 支持的 ChatOps 以及許多其他主題。盡管開發人員工具正在發展的日臻成熟，但我們始終對于“軟件開發的所有方面都可以從人工智能和相關工具的務實使用中受益”抱有懷疑，我們正在積極跟蹤相關領域的創新。與此同時，在人工智能帶來近乎神奇的新技能時，相

9、關的質量與安全風險也在涌現，這需要團隊保持警惕，包括讓非開發人員意識到潛在的風險。本期主題 Thoughtworks,Inc.All Rights Reserved.7涌現的大語言架構模式在技術領域，“模式”因為能夠為特定問題提供一個簡潔的解決方案名稱而受到歡迎。隨著大語言模型（LLMs）的日益普及，我們開始看到支持常見上下文的特定架構模式不斷涌現。例如，我們討論了 NeMo Guardrails，它允許開發人員圍繞 LLM 的使用建立治理政策。我們還討論了像 Langfuse 這樣的工具，它們能夠更好地觀察LLM 的輸出步驟，并知道如何處理（并驗證）充斥著生成代碼的臃腫代碼庫。我們討論了如何

10、使用檢索增強生成（RAG），這是我們偏愛的模式，以提高 LLM 輸出的質量，在企業生態系統中尤其有效。此外，我們還討論了使用低能耗（和成本）大語言模型產生材料，然后由更強大（也更劃算）的大語言模型選擇性審查的技術。模式為技術構建了一個重要的詞匯庫，隨著生成式 AI 繼續滲透軟件開發，我們預計會看到模式（以及不可避免的反模式）的爆炸式增長。讓 Pull Request（PR）更接近正確的持續集成Thoughtworks 一直推崇在軟件開發過程中采用快速反饋循環，因此也是持續集成（CI）的大力支持者。為此，我們在 20 世紀 90 年代末構建并開源了有史以來第一個 CI 服務器 Cruise Co

11、ntrol。最近，我們的首席科學家Martin Fowler 在他的 bliki 上更新了對于持續集成的規范定義，以重申對這一實踐的關注。然而，我們許多團隊被迫忽視 CI/CD 中的 CI 部分，因為他們發現自己處于必須使用 Pull Request（PR）的情況。盡管 PR 的做法最初是為了管理大規模分布式的開源團隊和不可靠的貢獻者，然而目前已經發展成了同行評審（Peer Review，PR）的同義詞，即使在緊密工作的小型團隊也是如此。在這些情況下，許多開發者渴望從實踐真正的 CI 中獲得相同的流暢感。我們調查了幾個試圖減輕 PR 審查過程痛苦的工具，包括 gitStream 和 Githu

12、b 合并隊列。我們還討論了諸如 stacked diffs 之類的技術，這些技術通過使集成過程更精細化，有望與 CI 的核心原則保持一致。除此之外，我們還探討了從 PR 中提取度量的方法，以識別軟件交付過程中的低效和瓶頸。工具在這個領域會起到巨大幫助，因為整體趨勢是朝向生成式 AI 編程的。隨著 AI 編碼助手的出現，編碼吞吐量增加，導致傾向于創建更大的 PR。這給異步代碼審查過程增加了更大的壓力。盡管我們仍然更喜歡原始的 CI 實踐，但我們鼓勵那些由于外部約束而無法使用 CI 的團隊尋找方法，從而提高集成準確性和反饋周期速度。Thoughtworks,Inc.All Rights Reser

13、ved.8188242930313233343536373839404142432623456791516171011121314444749506566676869707172737475767778798081828351525459535658616263648588899091929394959697989910010110210310486871921222028252723841051454648555760暫緩暫緩評估評估試驗試驗采納采納本期雷達新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.采納1.檢索增強生成（RAG）試驗2.

14、自動生成 Backstage 實體描述符3.將傳統 NLP 與 LLMs 相結合4.持續合規5.邊緣函數6.安全標兵7.Text to SQL8.追蹤健康債務狀況評估9.人工智能團隊助理10.對 LLM 對話進行圖分析11.基于大語言模型的 ChatOps12.大語言模型驅動的自主代理13.使用 GenAI 理解遺留代碼庫14.VISS暫緩15.廣泛集成測試16.過度熱衷使用大語言模型17.急于沖向大語言模型微調（fine-tune LLMs）18.適用于 SSR 網絡應用程序的 Web 組件采納19.CloudEvents試驗20.云上 Arm21.Azure Container Apps2

15、2.Azure OpenAI Service23.DataHub24.基礎設施編排平臺25.Pulumi26.Rancher Desktop27.Weights&Biases評估28.Bun29.Chronosphere30.DataOS31.Dify32.Elasticsearch Relevance Engine33.FOCUS34.Gemini Nano35.HyperDX36.IcePanel37.Langfuse38.Qdrant39.RISC-V 用于嵌入式40.Tigerbeetle41.WebTransport42.Zarf43.ZITADEL暫緩 技術平臺本期雷達 Thoug

16、htworks,Inc.All Rights Reserved.采納44.Conan45.Kaniko46.Karpenter試驗47.42Crunch API Conformance Scan48.actions-runner-controller49.Android 模擬器容器50.AWS CUDOS51.aws-nuke52.Bruno53.Develocity54.GitHub Copilot55.Gradio56.Gradle Version Catalog57.Maestro58.Microsoft SBOM 工具59.開放策略代理（OPA）60.Philipss self-hos

17、ted GitHub runner61.Pop62.Renovate63.Terrascan64.Velero評估65.aider66.Akvorado67.百川 268.Cargo Lambda69.Codium AI70.Continue71.Fern Docs72.Granted73.LinearB74.LLaVA75.Marimo76.Mixtral77.NeMo Guardrails78.Ollama79.OpenTofu80.QAnything81.System Initiative82.Tetragon83.Winglang暫緩 采納 試驗84.Astro85.DataComPy

18、86.Pinia87.Ray評估88.安卓適應性89.Concrete ML90.Crabviz91.Crux92.Databricks Asset Bundles93.Electric94.LiteLLM95.LLaMA-Factory96.MLX97.Mojo98.Otter99.Pkl100.Rust for UI101.vLLM102.Voyager103.WGPU104.Zig暫緩105.LangChain工具語言和框架 Thoughtworks,Inc.All Rights Reserved.技術1882429303132333435363738394041424326234567

19、91516171011121314444749506566676869707172737475767778798081828351525459535658616263648588899091929394959697989910010110210310486871921222028252723841051454648555760暫緩暫緩評估評估試驗試驗采納采納采納1.檢索增強生成（RAG）試驗2.自動生成 Backstage 實體描述符3.將傳統 NLP 與 LLMs 相結合4.持續合規5.邊緣函數6.安全標兵7.Text to SQL8.追蹤健康債務狀況評估9.人工智能團隊助理10.對 LLM

20、 對話進行圖分析11.基于大語言模型的 ChatOps12.大語言模型驅動的自主代理13.使用 GenAI 理解遺留代碼庫14.VISS暫緩15.廣泛集成測試16.過度熱衷使用大語言模型17.急于沖向大語言模型微調（fine-tune LLMs）18.適用于 SSR 網絡應用程序的 Web 組件新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.12技術1.檢索增強生成（RAG）采納檢索增強生成（Retrieval-augmented generation，RAG）是我們團隊提高大語言模型（LLM）生成響應質量的首選模式。我們已經在包括 Jugal

21、bandi AI Platform 在內的多個項目中成功使用了它。通過 RAG，相關且可信的文檔（如 HTML 和 PDF 格式）的信息被存儲在支持向量數據類型或高效文檔搜索的數據庫中，例如 pgvector、Qdrant 或 Elasticsearch Relevance Engine。在收到給定提示后，數據庫會被調取以檢索相關文檔，然后這些文檔會與提示結合在一起，為 LLM 提供更豐富的上下文。這樣一來輸出質量更高，且大大減少了幻覺現象。上下文窗口決定了 LLM 輸入的尺寸是有限的，這意味著需要選擇最相關的文檔。我們會通過重新排序來提升提示內容的相關性。文檔如果太大而無法計算嵌入，這意味著

22、它們必須被分割成更小的塊。這通常是一個困難的問題，其中一種方法是讓這些塊在某種程度上重疊。2.自動生成 Backstage 實體描述符試驗Spotify 推出的 Backstage 已成為我們客戶托管開發者體驗門戶的首選平臺。本身來說，Backstage 只是一個托管插件，在托管的同時提供管理構成平臺生態系統資產目錄的界面的 shell。任何由 Backstage 顯示或管理的實體都在 catalog-info 文件中配置，其中包含狀態、生命周期、依賴關系和 API 等其他細節的數據。默認情況下，單個實體描述符是手動編寫的，并且通常由負責相應組件的團隊進行維護和版本化。保持描述符的更新可能是乏

23、味的，并且會成為開發者采用過程中的障礙。此外，總有可能忽視變更或完全錯過某些組件。我們發現 自動生成 Backstage 實體描述符 更有效且不易出錯。大多數組織有現有的信息源可以啟動填充目錄條目的過程。良好的開發實踐，例如，在 AWS 資源上放置適當的標簽或向源文件添加元數據，可以簡化實體發現和描述符生成。這些自動化流程可以定期運行 比如每天一次 以保持目錄的新鮮和更新。3.將傳統 NLP 與 LLMs 相結合試驗大語言模型（LLMs）是自然語言處理（NLP）中的瑞士軍刀。但它們往往比較昂貴，且并非總是最合適的-有時候使用一個螺絲刀會更合適。實際上，在 將傳統 NLP 與 LLMs 相結合，

24、或者在將多種 NLP 與 LLMs 相結合，以實現用例并利用 LLMs 的實際需求能力的步驟方面有很大的潛力。傳統的數據科學和 NLP 方法，例如文檔聚類、主題識別和分類，甚至摘要生成，成本更低且可能更有效地解決你的使用案例問題的一部分。然后，在需要生成和總結較長文本，或將多個大型文檔合并時，我們使用 LLMs，以利用其較高的注意力跨度和記憶力。例如，我們已經成功地將這些技術結合使用，從一個大型單個趨勢文檔語料庫生成關于某一領域的全面趨勢報告，同時結合傳統聚類方法和 LLMs 的生成能力。4.持續合規試驗持續合規 是一種實踐，旨在確保軟件開發過程以及相關技術一直遵守行業法規和安全標準，這一過程

25、大量依賴自動化，人工操作可能會降低開發速度并引入錯誤。作為替代，組織可以自動化合規檢查和審計。他們可以將工具集成到軟件開發流水線中，使團隊能夠在開發過程的早期發現并處理合規問題。將合規規則和最佳實踐編碼化有助于在團隊間執行一致的政策和標準。它使用戶能夠掃描代碼變更中的漏洞、強制執行編碼標準以及追 Thoughtworks,Inc.All Rights Reserved.13蹤基礎設施配置變更，以確保它們滿足合規要求。最后，以上內容的自動化報告簡化了審計工作，并提供了清晰的合規證據。我們已經討論過諸如發布軟件物料清單（SBOMs）和應用軟件供應鏈層級建議的技術 很適合在早期進行這樣的嘗試。這種技

26、術的好處是多方面的。首先，自動化能夠帶來更安全的軟件，可以在早期識別并處理漏洞，其次，隨著手動任務的消除，開發速度也會加快。最后，還能夠降低成本和提高一致性。對于像軟件驅動汽車這樣的安全關鍵行業，自動化持續合規可以提高認證過程的效率和可靠性，最終造就更安全、更可靠的車輛。5.邊緣函數試驗盡管不是一個新概念，我也注意到通過內容交付網絡（CDNs）進行去中心化代碼執行的可用性和使用量正在增長。諸如 Cloudflare Workers 或 Amazon CloudFront Edge Functions 這樣的服務提供了一種機制，可以在靠近客戶地理位置的地方執行無服務器代碼片段。邊緣函數 不僅可以

27、在邊緣生成響應時提供更低的延遲，還可以在請求和響應從區域服務器出發和返回的途中，以特定位置的方式重寫它們。例如，你可能會重寫請求的 URL，以路由到一個特定服務器，該服務器擁有與請求正文中找到的字段相關的本地數據。這種方法最適合于短暫、快速運行的無狀態處理，因為邊緣的計算能力是有限的。6.安全標兵試驗安全標兵*指的是團隊成員中對技術和非技術交付決策的安全后果持有批判性思維的人。他們會向團隊領導提出這些問題和顧慮，并且對基本安全指南和要求有比較到位的理解。他們協助開發團隊在軟件交付的所有活動中都以安全意識進行思考，從而降低系統的整體安全風險。安全標兵不是一個單獨的職位，而是分配給現有團隊成員的責

28、任，這些成員需要由安全從業者進行培訓指導。通過這樣的培訓，安全標兵通過傳播知識，并作為開發團隊和安全團隊之間的橋梁，提高團隊的安全意識。安全標兵所做的事情中一個非常好的活動示例是威脅建模，它幫助團隊從一開始就將安全風險考慮在內。在團隊中任命和培訓安全標兵是一個很好的開始，但僅僅依賴標兵而沒有來自領導層的適當投入可能會導致問題。根據我們的經驗，建立安全意識需要整個團隊及管理者的投入。7.Text to SQL試驗Text to SQL 是一種用于將自然語言查詢轉換為可以由數據庫執行的 SQL 查詢的技術。盡管大語言模型能夠理解和轉換自然語言，但在你自己的 schema 中創建準確的 SQL 仍然

29、存在很大的挑戰。為此可以引入 Vanna，它是一個在 Python 中用于 SQL 生成的檢索增強生成（RAG）開源框架。Vanna 分兩步工作：首先你需要使用數據定義語言語句（DDLs）和示范 SQL 描述你的結構，并為它們創建嵌入向量，然后再用自然語言提出問題。盡管 Vanna 可以與任何大語言模型協作，我們還是推薦你評估 NSQL，它是一個用于 Text to SQL 任務的領域特定大語言模型。技術 Thoughtworks,Inc.All Rights Reserved.148.追蹤健康債務狀況試驗通過將健康度評級與其他服務級目標（SLO）同等對待，并據此確定增強的優先級，而不是僅僅關

30、注跟蹤技術債務，我們不斷體驗到團隊對其生態系統的改進。通過有效分配資源來解決與健康狀況相關的最有影響的問題，團隊和組織可以降低長期維護成本，更高效地發展產品。這種方法還能加強技術和非技術利益相關者之間的溝通，促進對系統狀態的共同理解。盡管不同組織的衡量標準可能有所不同（請參閱本博文 中的示例），但它們最終都有助于實現長期可持續性，并確保軟件保持適應性和競爭力。在瞬息萬變的數字環境中，專注于 跟蹤系統的健康狀況與債務，可為維護和增強系統提供結構化的循證戰略。9.人工智能團隊助理評估像 GitHub Copilot 這樣的 AI 編碼輔助工具目前主要是在幫助和增強個人工作的背景下討論的。然而，軟件

31、交付仍然是團隊工作，并將始終是團隊工作，因此你應該尋找創建 AI 團隊助理 的方法來幫助創建“10 倍團隊”，而不是一群孤立的 AI 輔助的 10 倍工程師。我們已經開始使用一種團隊輔助方法，通過結合提示和知識源來增強知識放大、技能提升和對齊。標準化的提示有助于在團隊環境中使用已經達成共識的最佳實踐，例如編寫用戶故事的技術和模板，或實施威脅建模等實踐。除了提示之外，通過檢索增強生成提供的知識源，可以從組織指南或行業特定的知識庫中提供與上下文相關的信息。這種方法使團隊成員能夠及時獲得他們需要的知識和資源。10.對 LLM 對話進行圖分析評估由大語言模型（LLMs）支持的聊天機器人正變得非常流行，

32、我們看到圍繞這些機器人的產品化和生產化都涌現出了許多新技術。其中一個產品化挑戰是理解用戶如何與這類聊天機器人展開交流，畢竟這種對話有多個發展方向。了解對話流的實際情況對于改進產品和提高轉化率至關重要。有一種技術對解決這一問題大有裨益，就是 對 LLM 對話進行圖分析（graph analysis for LLM-backed chats）。那些支持特定期望結果的聊天代理 如購物行為或成功解決客戶問題 通?？梢员硎緸橐粋€期望的狀態機。通過將所有對話加載到一個場景中，你可以分析它實際所處的模式，并尋找與預期狀態機的偏差。這有助于發現錯誤和進行產品改進。11.基于大語言模型的 ChatOps評估基于

33、大語言模型的 ChatOps*是通過聊天平臺（主要是 Slack）應用大語言模型的新興方式，允許工程師通過自然語言來構建、部署和操作軟件。這種方式有可能通過增強平臺服務的可發現性和用戶友好性來簡化工程工作流程。截至撰寫本文時，兩個早期示例分別是 PromptOps 和 Kubiya。然而，考慮到生產環境需要的精細管理，組織在讓這些工具接近生產環境前應該徹底評估它們。技術 Thoughtworks,Inc.All Rights Reserved.1512.大語言模型驅動的自主代理評估隨著像 Autogen 和 CrewAI 這樣的框架的出現，LLM（大型語言模型）驅動的自主代理 正在從單一代理和

34、靜態多代理系統發展到更先進的階段。這些框架允許用戶定義具有特定角色的代理，分配任務，并使代理通過委派或對話合作完成這些任務。類似于早期出現的單一代理系統，如 AutoGPT，單個代理可以分解任務，利用預配置的工具，并請求人工輸入。盡管這一領域仍處于開發的早期階段，但它發展迅速，并且擁有廣闊的探索空間。13.使用 GenAI 理解遺留代碼庫評估生成式人工智能（GenAI）和大語言模型（LLMs）可以幫助開發者編寫和理解代碼。在實際應用中，目前主要體現在較小的代碼片段，但更多的產品和技術正在涌現，用于 利用 GenAI 理解遺留代碼庫。這在遺留代碼庫文檔記錄不完整、或者過時的文檔具有誤導性時尤其有

35、用。例如，Driver AI 或 bloop 使用了 RAG，結合了語言智能、代碼搜索與 LLMs，以幫助用戶在代碼庫中定位自己的位置。更大的上下文窗口的新興模型也將幫助這些技術更適配大型代碼庫。GenAI 對遺留代碼的另一個有前景的應用是在大型機（mainframe）現代化領域，這里的瓶頸通常圍繞著需要理解現有代碼庫、并將這種理解轉化為現代化項目需求的逆向工程師。這些逆向工程師有了 GenAI 的幫助可以更快地完成工作。14.VISS評估Zoom 最近開源了其漏洞影響評分系統（Vulnerability Impact Scoring System）VISS。這個系統主要關注的是對安全措施的漏

36、洞評分的優先級排序。VISS 與通用漏洞評分系統（CVSS）的不同之處在于，它不側重于對最壞情況進行預測，而是試圖從防御者的角度更客觀地衡量漏洞的影響。為此，VISS 提供了一個基于網頁的 UI，基于多個參數來計算漏洞分數 這些參數按照平臺、基礎設施和數據組進行分類 包括對平臺的影響、影響的租戶數量、數據影響等。盡管我們對這個特定工具還沒有太多的實踐經驗，但我們認為這種基于行業上下文的優先級定制的評估方法是值得考慮的。15.廣泛集成測試暫緩當我們對自動化測試表示贊揚時，也持續看到許多組織在我們認為無效的 廣泛集成測試 上投入過多?！凹蓽y試”這個術語在表述上有些模糊不清，我們嘗試引用 Mart

37、in Fowler 在該主題上的 bliki 條目描述該分類指的是需要所有運行時依賴項的實時版本的測試。這樣的測試顯然是昂貴的，因為它需要具備所有必要基礎設施、數據和服務的全功能測試環境。管理所有這些依賴項的正確版本需要大量的協調工作，這往往會拖慢發布周期。最后，測試本身通常是脆弱且無用的。例如，要確定測試失敗是由于新代碼、版本依賴性不匹配還是環境不足，而錯誤信息很少有助于挖掘問題源頭。當然，這些批評并不意味著我們認為自動化的“黑盒”集成測試普遍存在問題，但我們的確發現了一種更有幫助的方法就是平衡對信心的需求與發布頻率?？梢韵燃僭O對運行時技術 Thoughtworks,Inc.All Righ

38、ts Reserved.16依賴項的一組響應來驗證被測試系統的行為，然后驗證這些假設的兩個階段來完成。第一階段使用服務虛擬化來創建運行時依賴項的測試替身，并驗證被測試系統的行為。這簡化了測試數據管理問題，并允許進行確定性測試。第二階段可以使用契約測試來驗證這些環境假設與真實依賴項。16.過度熱衷使用大語言模型暫緩在急于利用最新人工智能技術的過程中，許多組織正在試圖將大語言模型（LLMs）應用于各種應用，從內容生成到復雜的決策過程。LLMs 的吸引力不可否認；它們提供了看似毫不費力的解決方案來處理復雜問題，開發人員通?？梢钥焖賱摻ù祟惤鉀Q方案，而無需多年深入的機器學習經驗。當 LLM-based

39、 的解決方案多少能夠工作時，就迅速部署并轉向下一個任務，這可能頗具誘惑力。盡管這些基于 LLM 的價值證明是有用的，但我們建議團隊仔細考慮所使用的技術以及是否 LLM 真的是正確的最終階段解決方案。許多 LLM 可以解決的問題如情感分析或內容分類傳統的自然語言處理（NLP）可以更便宜、更容易地解決。分析 LLM 的作用，然后評估其他潛在解決方案，不僅可以減輕 過度熱衷使用大語言模型 的風險，還可以促進對人工智能技術的更細致理解和應用。17.急于沖向大語言模型微調（fine-tune LLMs）暫緩許多組織都在試圖將大語言模型（LLMs）應用于他們的產品、領域或組織知識，我們看到了太多 急于沖向

40、大語言模型微調（fine-tune LLMs）的情況。雖然這種操作的確可以強大到對特定任務的用例進行優化，但在許多情況下對大語言模型進行微調并不是必需的。最常見誤用是為了讓 LLM 應用程序了解特定的知識、事實或組織的代碼庫進行微調。在絕大多數場景下，使用檢索增強生成（RAG）可以提供更好的解決方案和更優的投入產出比。微調需要大量的計算資源和專家能力，并且比 RAG 面臨更多敏感和專有數據挑戰。此外當你沒有足夠的數據進行微調時，還有欠擬合（underfitting）的風險。又或者，當你擁有太多數據時（這倒不太常見），出現過擬合（overfitting）風險?？傊_到你所需要任務專業性的正確平衡

41、是比較困難的。在你急于為應用場景進行大語言模型微調前，需要仔細考慮這些權衡和替代方案。18.適用于 SSR 網絡應用程序的 Web 組件暫緩隨著 Next.js 和 htmx 等框架逐步被采納，我們看到服務端渲染（SSR）的使用越來越多。作為一種瀏覽器技術，在服務器上使用 web 組件并非易事。為了簡化這一過程，許多框架應運而生，有時甚至使用瀏覽器引擎來執行操作，但復雜性依然存在。我們的開發人員發現他們需要繞過一些障礙并付出額外努力來整合前端組件和服務端組件。比開發者體驗更糟糕的是用戶體驗：當自定義 web 組件需要在瀏覽器中加載和填充時，頁面加載性能會受到影響，即使使用預渲染和謹慎調整組件，

42、未樣式化內容的閃現或一些布局移動幾乎不可避免。正如我們在上一期技術雷達中提到的，我們的一個團隊因為這些問題不得不將他們的設計系統從基于 web 組件的Stencil遷移出去。最近，我們從另一個團隊收到報告，他們最終用瀏覽器端組件替換了服務器端生成的組件，其原因是開發的復雜性。我們建議謹慎使用 用于 SSR web 應用的 web 組件，即使框架支持。技術 Thoughtworks,Inc.All Rights Reserved.平臺1882429303132333435363738394041424326234567915161710111213144447495065666768697071

43、72737475767778798081828351525459535658616263648588899091929394959697989910010110210310486871921222028252723841051454648555760暫緩暫緩評估評估試驗試驗采納采納采納19.CloudEvents試驗20.云上 Arm21.Azure Container Apps22.Azure OpenAI Service23.DataHub24.基礎設施編排平臺25.Pulumi26.Rancher Desktop27.Weights&Biases評估28.Bun29.Chronosphe

44、re30.DataOS31.Dify32.Elasticsearch Relevance Engine33.FOCUS34.Gemini Nano35.HyperDX36.IcePanel37.Langfuse38.Qdrant39.RISC-V 用于嵌入式40.Tigerbeetle41.WebTransport42.Zarf43.ZITADEL暫緩 新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.1819.CloudEvents采納事件是事件驅動架構或無服務器應用中的常見機制。然而，生產者或云提供商對它們的支持形式卻存在很大差異，這阻礙了跨

45、平臺和基礎設施的互操作性。CloudEvents 是一種規范，用于以通用格式描述事件數據，以實現跨服務、平臺和系統的互操作性。它提供了多種語言的 SDK，因此你可以將該規范嵌入到你的應用程序或工具鏈中。我們的團隊不僅將其用于跨云平臺，還用于領域事件規范以及其他場景。CloudEvents 由云原生計算基金會（CNCF）托管，現已成為一個畢業項目。我們的團隊默認使用 CloudEvents 構建事件驅動架構，因此我們正將其移入采納狀態。20.云上 Arm試驗近年來，由于與傳統基于 x86 的實例相比更具有成本和能源效率優勢，云上的 Arm 計算實例變得越來越受歡迎。許多云服務提供商現在都提供基于

46、 Arm 的實例，包括 AWS、Azure 和 GCP。云上 Arm 的成本優勢對于運行大型工作負載或需要擴展的企業特別有利。我們看到許多團隊將工作負載（如 JVM 服務甚至數據庫（包括 RDS）遷移到 Arm 實例，無需更改代碼，構建腳本的更改也很小。新的基于云的應用程序和系統越來越默認使用云中的 Arm。根據我們的經驗，我們建議所有工作負載使用 Arm 計算實例，除非存在特定于架構的依賴。支持多架構的工具，如多架構 Docker 鏡像，也簡化了構建和部署工作流。21.Azure Container Apps試驗Azure Container Apps 是一個托管的 Kubernetes 應

47、用平臺，能夠簡化容器化工作負載的部署。與 Azure Kubernetes Service（AKS）相比，運行容器化應用程序的操作和管理負擔相對較少，但這是以犧牲一些靈活性和控制權為代價的，也是團隊需要權衡的。這個領域的另一個產品，Azure Container Instances，通常不能滿足生產環境的需求。我們的團隊去年開始使用 Azure Container Apps，當時它還處于公開預覽階段，但那時它已經能在運行大容器時取得良好的結果?，F在它已經普遍可用，我們正在考慮將其應用于更多用例。Dapr 和 KEDA Autoscaler 都是在其支持范圍。22.Azure OpenAI Se

48、rvice試驗Azure OpenAI Service 通過 REST API、Python SDK 和基于 Web 的界面提供對 OpenAI 的 GPT-4、GPT-3.5-Turbo、Embeddings、DALL-E 模型等的訪問。這些模型可以適用于內容生成、提取摘要、語義搜索和將自然語言轉換為代碼等任務。通過小樣本學習（few-shot learning）和自定義超參數（hyperparameters），還可以進行微調。與 OpenAI 自己的 API 相比，Azure OpenAI 服務受益于 Azure 的企業級安全性和合規性功能，可在更多地區使用（盡管在更多地理區域可用性有限）

49、，并支持私有網絡、內容過濾和手動模型版本控制?；谏鲜鎏匦砸约拔覀冊诰唧w使用中的積極體驗，我們推薦已經使用 Azure 的企業考慮使用 Azure OpenAI Service，而不是 OpenAI API。平臺 Thoughtworks,Inc.All Rights Reserved.1923.DataHub試驗在使用 數據產品思維 構建產品時，數據血緣、數據可發現性、數據治理非常重要。我們的團隊發現 DataHub 在這些方面能提供非常有效的支持。DataHub 的早期版本在需要更新元數據模型時，要求用戶手動復制管理來自主產品的同步。近期的更新引入了通過插件實現的元數據模型定制。DataH

50、ub 的另一個有用功能是從源頭到處理再到消費的強大端到端數據脈絡。DataHub 既支持基于推送的集成，也支持基于拉動的數據血緣提取，可自動抓取跨數據源、調度器、協調器（通過掃描 Airflow DAG）、處理管道任務和儀表板等元數據。作為完整數據目錄的一個開源選項，DataHub 逐漸成為我們團隊的默認選擇。24.基礎設施編排平臺試驗組織內部的基礎設施編排代碼庫頻繁地成為維護和排查故障的時間黑洞?；A設施編排平臺 應運而生，試圖將基礎設施代碼交付和部署工作流的各個方面變得標準化和產品化。其中包括構建一些工具，例如 Terragrunt、Terraspace；以及 IaC 工具供應商的服務，如

51、Terraform Cloud和Pulumi Cloud，以及與工具無關的平臺和服務，如env0和Spacelift。Terraform 特定的編排工具和服務有一個豐富的生態系統，通常被稱為TACOS（Terraform Automation and Collaboration Software），包括 Atlantis、Digger、Scalr、Terramate 和 Terrateam。每個平臺支持不同的工作流程，包括 GitOps、持續交付和代碼合規性。我們很期待看到這一領域涌現出更多解決方案。我們建議基礎設施和平臺工程團隊探索如何使用這些解決方案，從而減少他們開發和維護基礎設施所需的差

52、異不大的自定義代碼量?；A設施代碼的結構化、共享、交付和部署的標準化也能夠為測試、度量和監控基礎設施的兼容工具生態系統的出現創造機會。25.Pulumi試驗在基礎設施即代碼領域，工具仍在不斷進化，我們很高興地看到 Pulumi 也不例外。該平臺最近新增了對 Java 和 YAML 的支持，用于管理大規?；A設施，以及支持眾多云配置和集成，使得該平臺更加引人注目。對于我們的團隊來說，它仍然是 Terraform 的主要替代品，用于開發多個云平臺的代碼。26.Rancher Desktop試驗Docker Desktop 許可證的變更迫使我們尋找相關替代方案，以便開發時能夠在本地筆記本電腦上運行一

53、系列容器。最近我們在使用 Rancher Desktop 上取得了不錯的成效。這款免費且開源的應用程序容易下載并能夠安裝在蘋果、Windows 或 Linux 機器上，便捷地提供了一個帶有圖形界面配置和監控的本地 Kubernetes 集群。雖然 Colima 已成為我們 Docker Desktop 的首選替代品，但它主要是一個 CLI 工具。相比之下，Rancher Desktop 對那些不想放棄 Docker Desktop 提供的圖形界面的用戶很有吸引力。像 Colima 一樣，Rancher Desktop 允許你選擇 dockerd 或 containerd 作為底層容器運行時。選

54、擇直接使用 containerd 可以讓你擺脫對 DockerCLI 的依賴，但 dockerd 選項也提供了與其他工具的兼容性，這樣可以與運行時守護進程進行通信。平臺 Thoughtworks,Inc.All Rights Reserved.2027.Weights&Biases試驗Weights&Biases 是一個機器學習（ML）平臺，它通過實驗跟蹤、數據集版本控制、模型性能可視化和模型管理來幫助更快地構建模型。它可以集成到現有的 ML 代碼中，以便將實時指標、終端日志和系統統計數據實時傳輸到儀表板進行進一步分析。近期，Weights&Biases 擴展到了與大語言模型可觀測性相關的 T

55、races。Traces 可視化了提示鏈的執行流程以及中間的輸入/輸出，并提供了關于鏈執行的元數據（例如使用的 token 和開始與結束時間）。我們的團隊發現它對于調試和更深入了解鏈式架構非常有用。28.Bun評估Bun 是一個新的 JavaScript 運行時，類似于 Node.js 或 Deno。然而，與 Node.js 或 Deno 不同，Bun 是使用 WebKit 的 JavaScriptCore 而不是 Chrome 的 V8 引擎構建的。作為 Node.js 的替代品設計，Bun 是一個單一的二進制文件（用 Zig 編寫），充當 JavaScript 和 TypeScript 應

56、用程序的打包器、轉譯器和包管理器。自上一期技術雷達發布以來，Bun 已經從測試版發展到穩定的 1.0 版本。Bun 從頭開始構建，并進行了幾項優化包括快速啟動、改進的服務器端渲染和一個更快的替代包管理器我們鼓勵你評估它作為你的 JavaScript 運行時引擎。29.Chronosphere評估在管理分布式架構時，考慮排序、索引和訪問數據的成本與可觀測性同樣重要。Chronosphere 使用了獨特的方法來管理成本、跟蹤可觀測數據的使用情況，以便組織可以考慮并權衡各種指標的成本價值。借助 Metrics Usage Analyzer，作為 Chronosphere Control Plane

57、的一部分，團隊可以識別并排除他們很少（或從未）使用的指標，進而通過減少組織必須梳理的數據量來節省大量成本?？紤]到這些優勢，以及 Chronosphere 與其他云托管解決方案的可觀測性工具匹配的能力，我們認為它非常值得投入使用。30.DataOS評估隨著越多越多人開始使用 data mesh，我們的團隊一直在尋找將數據產品作為最高優先級對待的數據平臺。DataOS 就是這樣一款產品。它提供了從設計、構建、部署到演進數據產品的端到端生命周期管理。它提供標準化的聲明式規范（用 YAML 編寫），抽象了底層基礎設施設置的復雜性，允許開發人員通過 CLI/API 輕松定義數據產品。它支持訪問控制策略與

58、 ABAC 以及數據策略用于過濾和脫敏數據。另一個值得注意的特性是它將數據聯邦化到多種數據源的能力，這減少了數據重復和數據向中心地點的轉移。DataOS 最適合于綠地場景，因為它提供了數據治理、數據可發現性、基礎設施資源管理和可觀測性的開箱即用解決方案。對于棕地場景，在 DataOS 外部編排資源（例如，像 Databricks 這樣的數據堆棧）的能力還處于起步階段，并且仍在不斷發展中。如果你的生態系統能夠接納數據工具，DataOS 是加快你構建、部署和以端到端方式使用數據產品的不錯選擇。平臺 Thoughtworks,Inc.All Rights Reserved.2131.Dify評估Di

59、fy 是一個 UI 驅動的用于開發大語言模型應用程序的平臺，它使原型設計更加容易訪問。它支持用戶使用提示詞模板開發聊天和文本生成應用。此外，Dify 支持使用導入數據集的檢索增強生成（RAG），并且能夠與多個模型協同工作。我們對這類應用很感興趣。不過，從我們的使用經驗來看，Dify 還沒有完全準備好投入大范圍使用，因為某些功能目前仍然存在缺陷或并不成熟。但目前，我們還沒有發現更好的競品。32.Elasticsearch Relevance Engine評估盡管向量數據庫因 檢索增強生成（RAG）使用案例而日益流行，但研究和經驗報告表明，將傳統的全文搜索與向量搜索相結合（成為混合搜索）可以生成更

60、完善的結果?？梢越柚?Elasticsearch Relevance Engine（ESRE），成熟的全文搜索平臺 Elasticsearch 支持了內置和自定義嵌入模型、向量搜索以及具有如倒數排序融合（Reciprocal Rank Fusion）等排名機制的混合搜索。盡管這個領域仍在發展中，但根據我們的經驗，使用 ESRE 的這些功能以及 Elasticsearch 自帶的傳統過濾、排序和排名功能已經取得不錯的結果，這表明支持語義搜索的搜索平臺不應被忽視。33.FOCUS評估云和 SaaS 計費數據可能非常復雜，不同供應商之間存在許多不一致。FinOps Open Cost and Usa

61、ge Specification（FOCUS）旨在通過提供包含一組專業術語的規范（和 FinOps framework 對齊）、一個模式和一組最低要求的計費數據來減少此類問題。規范旨在支持各類 FinOps 從業者常見的用例。即便它目前仍然處于早期開發和采用階段，也是值得關注的。隨著行業采用的增長，FOCUS 將使平臺和終端用戶更容易、更全面地了解在云和 SaaS 供應商那里的長尾支出情況34.Gemini Nano評估Google 的 Gemini 是一系列基礎性大語言模型，用于在從數據中心到手機等各種硬件上運行。其團隊已經對 Gemini Nano 做了特別對優化和簡化，以便在移動芯片加速

62、器上運行。它可以實現高質量的文本摘要、上下文智能回復和高級語法糾正等功能。例如，Gemini Nano 的語言理解能力使得 Pixel 8 Pro 能夠在錄音機應用中總結內容。在設備上運行消除了許多來自云的系統相關的延遲和隱私問題，并且能夠在沒有網絡連接的情況下工作。Android AICore 簡化了將模型集成到 Android 應用中的過程，但在撰寫本文時只支持少數設備。35.HyperDX評估HyperDX 是一個開源的可觀測性平臺，整合了可觀測性的三大支柱：日志、指標和追蹤。在它的幫助下，可以實現端到端的關聯，并且只需幾次點擊就能從瀏覽器會話回放跳轉到日志和追蹤信息。該平臺使用 Cli

63、ckHouse 平臺 Thoughtworks,Inc.All Rights Reserved.22作為所有遙感數據的中心數據存儲，能夠擴展以聚合日志模式，并將數十億事件壓縮成獨特的集群。雖然這并不是唯一可選的可觀測性平臺，但我們在這里想特別強調 HyperDX 統一的開發者體驗。36.IcePanel評估IcePanel 通過使用 C4 模型，促進了協作式的架構建模和圖表繪制，使技術和業務利益相關者能夠根據需要深入到所需的技術細節級別。它支持建模架構對象，這些對象的元數據和連接可以在多個圖表中重用，并且能夠將這些對象之間的交互 可視化出來。版本控制和標簽使協作者能夠模擬不同的架構狀態（例如，

64、現狀與未來），并跟蹤架構各部分的用戶定義分類。我們正在關注 IcePanel，因為它有潛力改善架構協作，特別是對于擁有復雜架構的組織。如果你正在尋找更好的支持圖表即代碼的替代產品，請查看 Structurizr。37.Langfuse評估Langfuse 是一個用于觀察、測試和監控大語言模型應用的工程平臺。其 SDK 支持 Python、JavaScript 和 TypeScript，以及其他語言框架，如 OpenAI、LangChain 和 LiteLLM。用戶可以自行托管開源版本，也可以將其用作付費云服務。我們的團隊在使用它調試復雜的 LLM 鏈、分析完成情況以及跨用戶、會話、地理、功能和

65、模型版本監控關鍵指標（如成本和延遲）方面體驗良好。如果你希望構建基于數據驅動的大語言模型應用程序，Langfuse 是一個值得考慮的好選擇。38.Qdrant評估Qdrant 是一個使用 Rust 實現的開源向量數據庫。在 2023 年 9 月的數據雷達中，我們提到過 pgvector，一個基于 PostgreSQL 的插件，可用于向量搜索。然而，如果你需要在多個節點之間橫向擴展向量數據庫，我們建議考慮一下 Qdrant。它內置的單指令/多數據（SIMD）加速支持可提升搜索表現，它還能幫助你將 JSON 格式的負載（payload）與向量關聯起來。39.RISC-V 用于嵌入式評估隨著 Arm

66、 架構繼續擴大其影響力 我們在本期雷達更新了對云上 Arm 的評估 對更新但不那么成熟的 RISC-V 架構的興趣也在增長。RISC-V 并沒有在性能或效率方面帶來突破 實際上，它的每瓦性能與 Arm 相似，且在絕對性能上無法與之競爭 但它是開源的、模塊化的，且不依賴于單一公司。這使得它成為嵌入式系統中的一個有吸引力的選擇，因為在這些系統中，架構的許可專有成本是一個重要的考慮因素。這也是為什么 RISC-V 用于嵌入式 領域日臻成熟，以及包括 SiFive 和 espressif 在內的幾家公司正在為廣泛的應用提供開發板和 SoCs。如今，能夠運行 Linux 內核的微控制器和微處理器以及相應

67、的軟件棧和工具鏈都已可用。我們正在關注這一領域，并預計在未來幾年內看到更多的采用。平臺 Thoughtworks,Inc.All Rights Reserved.23平臺40.Tigerbeetle評估Tigerbeetle 是一個用于財務會計的開源分布式數據庫。與其他數據庫不同的是，它被設計成特定領域的狀態機，以確保安全性和性能。集群中一個節點的狀態通過 Viewstamped Replication 共識協議，以確定性順序復制到其他節點。我們非常喜歡 Tigerbeetle 背后的 設計決策，使其實現具有嚴格可序列化保證的復式記賬。這是一個相對較新且正在積極發展的數據庫，尚未完全準備好投入

68、生產使用41.WebTransport評估WebTransport 是一種建立在 HTTP/3 之上的協議，提供了服務器與應用之間的雙向通信。與其前身 WebSocket 相比，WebTransport 具有很多優勢，包括更快的連接、更低的延遲，以及能夠處理可靠且有序的數據流以及無序數據流（例如 UDP）。它可以在同一連接中處理多個流，而不會造成隊頭阻塞（head-of-line blocking），進而實現在復雜應用中更高效地通信?？傮w來說，WebTransport 適用于廣泛的用例，包括實時網絡應用、流媒體和物聯網數據通信。盡管 WebTransport 還處于早期階段各瀏覽器的支持正逐漸

69、成熟，流行的庫如 http:/socket.io 也增加了對 WebTransport 的支持我們的團隊目前正在評估其在實時物聯網應用中的潛力。42.Zarf評估Zarf 是一個用于離線和半連接 Kubernetes 環境的聲明式軟件包管理器。使用 Zarf，可以在連接到互聯網時構建和配置應用程序；一旦創建完成，可以將其打包并發送到斷開連接的環境以進行部署。作為一個獨立的工具，Zarf 提供了幾個有用的功能，包括自動生成軟件物料清單（SBOM）、內置的 Docker 注冊表，Gitea 和 K9s 儀表板，可從終端管理集群。云原生應用程序的網閘軟件交付面臨著挑戰，Zarf 解決了其中大部分的問

70、題。43.ZITADEL評估ZITADEL 是一個開源的用戶身份管理工具，也是 Keycloak 的替代品之一。它非常輕量級（用 Golang 編寫），擁有靈活的部署選項，并且易于配置和管理。它還是多租戶的，能夠提供全面的功能以構建安全且可擴展的認證系統，特別是對于 B2B 應用程序，并且具有內置的安全功能，如多因素認證和審計追蹤。通過使用 ZITADEL，開發者可以減少開發時間，增強應用程序的安全性，并為不斷增長的用戶基礎進行擴容。如果你正在尋找一個用戶友好、安全且開源的用戶管理工具，ZITADEL 是一個不錯的選擇。Thoughtworks,Inc.All Rights Reserved.

71、工具采納44.Conan45.Kaniko46.Karpenter試驗47.42Crunch API Conformance Scan48.actions-runner-controller49.Android 模擬器容器50.AWS CUDOS51.aws-nuke52.Bruno53.Develocity54.GitHub Copilot55.Gradio56.Gradle Version Catalog57.Maestro58.Microsoft SBOM 工具59.開放策略代理（OPA）60.Philipss self-hosted GitHub runner61.Pop62.Reno

72、vate63.Terrascan64.Velero評估65.aider66.Akvorado67.百川 268.Cargo Lambda69.Codium AI70.Continue71.Fern Docs72.Granted73.LinearB74.LLaVA75.Marimo76.Mixtral77.NeMo Guardrails78.Ollama79.OpenTofu80.QAnything81.System Initiative82.Tetragon83.Winglang暫緩 1882429303132333435363738394041424326234567915161710111

73、21314444749506566676869707172737475767778798081828351525459535658616263648588899091929394959697989910010110210310486871921222028252723841051454648555760暫緩暫緩評估評估試驗試驗采納采納新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.2544.Conan采納Conan 是一個用于 C/C+應用程序的開源依賴管理工具。它提供了直觀的界面來定義、獲取和管理依賴，使開發人員能夠輕松地將第三方庫集成到他們

74、的項目中。Conan 支持所有主要操作系統，并可以適用于多種平臺，包括服務器和桌面、移動和嵌入式設備。它也可以用于構建和發布 C/C+庫和包。這些包可以通過 JFrog Artifactory 服務器在團隊間共享。通過利用預構建的二進制文件，它顯著節省了構建時間，特別是對于龐大的依賴。Conan 與流行的構建系統如 CMake 進行了集成，并擁有 Python SDK 用于擴展構建系統，以執行諸如簽名之類的任務。根據我們的經驗，Conan 改善了環境間的構建可重復性并加速了開發周期。這讓代碼庫更加清晰易維護，對于大規模 C 和 C+項目而言是一個重要進步。如果你在項目中苦于依賴管理，Conan

75、 絕對是提升開發效率的必要工具。45.Kaniko采納我們在 2022 年 10 月的技術雷達中加入了 Kaniko，就在 Kubernetes 停止支持 Docker 之后不久。當時我們強調了 Docker 作為構建基于容器流水線中容器鏡像的默認工具的趨勢。從那以后，我們在不同流水線的工具和配置上增加了對 Kaniko 的使用經驗。我們團隊欣賞它的靈活性和性能，這就是為什么我們要將其移到“采納”階段，以此來強調 Kaniko 應當成為這一領域的默認工具。46.Karpenter采納Kubernetes 的一個基本功能是水平自動伸縮：它能夠在需要額外容量時啟動新的 pods，并在負載減少時將它

76、們關閉。然而，這只有在需要托管 pods 的節點已經存在時才有效。Cluster Autoscaler 可以做一些基本的集群擴展，由 pod 故障觸發，但它的靈活性有限；然而，Karpenter 是一個更智能的、開源的 Kubernetes Operator 節點自動伸縮器：它分析當前工作負載和 pod 調度約束，選擇適當的實例類型，然后根據需要啟動或停止它。Karpenter 是一個像 Crossplane 這樣的工具，它可以在集群外部配置云資源的操作者。盡管 Karpenter 最初是由 AWS 為 EKS 開發的，但它正在成為云 Kubernetes 服務提供商中默認的節點自動配置器，而

77、 Azure 最近開始支持 Karpenter，推出了 AKS Karpenter Provider。47.42Crunch API Conformance Scan試驗42Crunch API Conformance Scan 是一個動態測試工具，用于識別 API 文檔中記錄的行為與其實際實現之間的差異。此工具使用 OpenAPI 格式的 API 規格定義，概述了預期的功能和響應，并將其與 API 的實際行為進行比較。通過生成真實流量并與現場端點交互，該工具能夠識別 API 承諾與其實際提供之間的任何差異。這為開發團隊帶來了很多好處。例如，它能在開發早期捕捉到不一致性，節省時間并防止問題進入

78、生產環境。該工具還通過識別可能由于偏離記錄行為而產生的潛在漏洞，幫助提高 API 的質量和安全性?？偟膩碚f，API Scan 能夠通過識別諸如弱認證協議、不安全的數據處理實踐和不充分的輸入驗證等問題，幫助評估 API 的安全態勢。它能提供詳細的報告，突出顯示發現的問題以及修復建議。工具 Thoughtworks,Inc.All Rights Reserved.2648.actions-runner-controller試驗actions-runner-controller 是一個 Kubernetes 控制器，用于操作 GitHub Actions 的自托管運行器。在需要訪問 GitHub c

79、loud runner 無法訪問的資源，或具有與 GitHub 提供的不同的特定操作系統和環境要求的情況下，自托管運行器非常有幫助。這時如果團隊使用 Kubernetes 集群，actions-runner-controller 將協調和擴展這些 runner。我們的團隊非常贊賞它能夠根據給定倉庫、組織、企業或 Kubernetes 集群中運行的工作流數量來擴展 runner 的能力，以及它可以很好地處理 Linux 和 Windows runner。49.Android 模擬器容器試驗Android Emulator Container 通過消除因操作系統兼容性問題和系統依賴，以及設置多個

80、Android 版本的模擬器所帶來的復雜性，使得 Android 應用測試變得更為簡便。傳統上，這些復雜性會帶來額外的工作量致使團隊完全放棄自動化測試，進而導致開發和測試周期變慢。Android 模擬器容器簡化了這個過程，使其可以無縫集成到 CI 流水線中進行自動化測試。我們的團隊主要使用這些容器進行設備化測試，這些測試會在每次提交時自動執行，為開發者提供即時反饋。此外，我們還使用 Android 模擬器容器來運行夜間的端到端測試。50.AWS CUDOS試驗我們一如既往地認為應當將成本監控列為適應性函數。云服務商提供了各種監控云消費的服務，例如 AWS Cost Explorer 或 Goo

81、gle Cloud FinOps Hub。在 AWS 生態系統中，我們的團隊使用 CUDOS（Cost and Usage Dashboards Operations Solution）來監控大型母公司下不同業務部門或法律實體在 AWS Marketplace 的消費。該儀表板提供了全面的成本和使用細節，具有資源級別的細粒度，有助于優化成本、跟蹤使用目標并實現運營卓越。51.aws-nuke試驗aws-nuke 是一個開源工具，解決了開發和沙箱 AWS 賬戶中積累未使用資源導致成本效率低下的常見挑戰。該工具可以識別并刪除 AWS 賬戶或區域內所有可刪除的資源，除了默認或 AWS 管理的資源，本

82、質上是要將環境重置為第一天的狀態。它還提供自定義排除策略，以確保關鍵資源得到保護。我們已經在成本優化的默認用例以及災難恢復（DR）環境中成功使用了這個工具。通過自動化清理開發和沙箱環境，aws-nuke 幫助最小化不必要的資源開銷。它還有助于在演習或練習后高效拆除臨時 DR 基礎設施。盡管穩定，aws-nuke 是一個非常具有破壞性的工具，不適用于生產環境。請始終進行試運行，以確認不會刪除必要資源。52.Bruno試驗Bruno 是 Postman 和 Insomnia 的開源桌面替代品，用于 API 的測試、開發和調試。它將測試集合保存在本地，因此可以使用 Git 或其他版本控制工具來進行協

83、作。目前有一些 Thoughtworks 團隊正在使用 Bruno，他們喜歡它簡單并且僅支持離線使用的設計。工具 Thoughtworks,Inc.All Rights Reserved.2753.Develocity試驗Develocity（之前是 Gradle Enterprise）解決了大型軟件項目長時間的構建和測試周期的痛點。它采用構建緩存和預測試選擇來提升性能從而縮短開發人員在本地和 CI/CD 環境中的反饋循環。我們的平臺團隊發現這對于加速構建和測試、分析命令以確定工作流程中哪些部分仍需優化、識別和解決不穩定的測試以及對運行測試的硬件進行分析非常有用。54.GitHub Copil

84、ot試驗盡管 AI 編碼輔助市場愈發壯大，GitHub Copilot 仍然是我們的首選，且被許多團隊廣泛使用。自上次我們介紹 GitHub Copilot 以來，最有趣的改進來自于聊天功能。例如，不再需要用注釋作為提示，這樣會使代碼變得混亂；相反，內置聊天可以幫助提示用戶，而無需撰寫注釋。內聯聊天還可以更改代碼，而不僅僅是編寫新行?，F在還可以通過使用 workspace 標簽，顯著擴展聊天時詢問有關代碼問題的上下文。這使得用戶可以詢問有關整個代碼庫的問題，而不僅僅是打開的文件。你可以通過使用 Copilot Enterprise 版本進一步擴展此上下文，該版本會從你在 GitHub 上托管的

85、所有存儲庫中提取上下文。最后，GitHub 已經開始將一些聊天請求路由到更強大的基于 GPT-4 的模型，并且在流行的 Jetbrains IDE 中即將推出聊天功能（盡管在撰寫本文時仍處于內測階段）。這些發布表明，這一領域的改進步伐并未減緩。如果你去年嘗試過編碼助手卻最終放棄，我們建議你持續關注新發布的功能，并再次嘗試。55.Gradio試驗Gradio 是一個開源的 Python 庫，它能幫助機器學習（ML）模型創建基于 web 的交互式界面。ML 模型上的圖形 UI 能夠幫助非技術受眾更好地理解輸入、約束和輸出。Gradio 在生成式人工智能領域獲得了大量關注，因為它讓生成式模型更易于嘗

86、試和使用。通常，我們只有在生產環境中真正使用過才會將一個技術放在雷達的試驗環。目前，我們團隊已經多次使用它并在最近的一次大型活動中，幫助客戶使用 Gradio 做了一次現場演示。我們對 Gradio 在這些用例中展現的效果非常滿意，因此將其移入“試驗”環。56.Gradle Version Catalog試驗Gradle 版本目錄是 Gradle 構建工具的一個有用的功能，它允許你集中管理構建文件中的依賴項。我們的團隊發現它在 Android 多模塊項目中特別有用。你可以為這些依賴項創建一個中央版本目錄，然后在 Android Studio 的幫助下以一種類型安全的方式引用它，而不是在單獨的構

87、建文件中硬編碼依賴項名稱和版本號并管理升級。57.Maestro試驗Maestro 在測試移動應用程序中的復雜流程時非常有用。它易于學習和理解，并且可以很方便地集成到我們的開發工作流程中。Maestro 支持一系列移動平臺，包括 iOS、Android、React Native 和 Flutter 應用。其聲明式的 YAML 語法簡化了復雜移動 UI 交互的自動化。從工具的演進來看，它的增強功能值得關注，如全面的 iOS 工具 Thoughtworks,Inc.All Rights Reserved.28支持以及引入了諸如 Maestro Studio 和 Maestro Cloud 之類的工

88、具，我們鼓勵任何希望優化其移動應用程序測試流程的人嘗試一下。58.Microsoft SBOM 工具試驗Microsoft SBOM 工具 是一個開源工具，用于生成與 SPDX 兼容的軟件物料清單（SBOM）。我們之前已經提到過軟件物料清單，而這個工具其變得更加容易。SBOM 工具支持多種流行的包管理器（包括 npm、pip 和 Gradle），所以可以與許多項目兼容。它非常易于使用，可以集成到現有的開發工作流中，包括與 CI/CD 流水線的集成。借此開發者獲得了多重優勢，其中改善軟件安全是一個關鍵好處，因為清晰的組件視圖可以幫助識別漏洞和管理風險。許可證合規性也得到增強，因為開發者可以確保遵

89、守所有相關協議。此外，SBOM 在軟件供應鏈中促進透明度，幫助跟蹤依賴性和緩解潛在風險。如果你正在尋求簡化 SBOM 生成、提升軟件安全性以及控制你的軟件供應鏈，你應該嘗試一下 Microsoft SBOM 工具。59.開放策略代理（OPA）試驗Open Policy Agent（OPA）是一個統一的框架和語言，用于聲明、執行和控制策略。在我們團隊，它已經成為定義分布式系統策略的一種常用方式，尤其是在我們需要實施變更點的合規時。OPA 使團隊能夠實現各種平臺工程模式，例如控制部署到 Kubernetes 集群的內容、在服務網格 中跨服務強制訪問控制以及實現細粒度的訪問應用程序資源的 安全策略即

90、代碼。雖然 OPA 實現存在一定復雜性，但事實證明它是一種確保 DevOps 文化下的合規性的非常有價值的工具。我們還將繼續關注 OPA 在運營系統之外擴展到大數據解決方案的成熟度。60.Philipss self-hosted GitHub runner試驗雖然 GitHub Actions runners 已經覆蓋了最常見的運行時環境，并且是最早投入使用的，但有時團隊還是需要管理自托管運行器，比如當組織政策只允許從組織內部的安全邊界內部署到私有托管基礎設施時。在這種情況下，團隊可以使用 Philipss self-hosted GitHub runner，這是一個 Terraform 模塊

91、，可以在 AWS EC2 競價實例（spot instance）上啟動自定義運行器。該模塊還創建了一組 Lambda 用于處理這些運行器的生命周期管理（擴展和縮減）。根據我們的經驗，這個工具極大地簡化了自托管 GitHub Actions runner 的配置和管理。對于使用 Kubernetes 的團隊來說，另一種選擇是 actions-runner-controller。61.Pop試驗結對編程對于我們來說是一項必不可少的實踐，因為它能幫助我們提高代碼質量，在團隊內傳播知識。雖然結對編程最好發生在線下，面對面進行，但在不可避免要進行線上結對時，我們的團隊成員也為此探索了很多工具，比如 Tu

92、ple，Visual Studio Live Share，Code With Me，和通用的聊天及會議工具。Pop（前身為 Screen）作為這個領域最新的工具引起了我們的關注，它來源于 Screenhero 的創建者，支持多人屏幕分享、編寫注釋和進行高質量音頻/視頻通話。我們有些團隊正在頻繁使用它來進行結對編程和遠程工作會議，他們對該軟件體驗反饋非常正向。工具 Thoughtworks,Inc.All Rights Reserved.2962.Renovate試驗作為軟件構建過程的一部分，自動監控和更新依賴項已成為整個行業的標準實踐。這樣一來，在開源軟件包發布安全更新時，用戶不必盲目猜測。多

93、年來，Dependabot 一直是這一實踐的標準工具，但 Renovate 在出現后逐漸成為許多團隊的第一選擇。他們發現 Renovate 更適合現代軟件開發環境，其中可部署的系統不僅依賴于代碼和庫，還包括運行時工具、基礎設施和第三方服務。除了代碼之外，Renovate 還涵蓋了對這些輔助工件的依賴性。我們的團隊還發現 Renovate 通過配置和定制選項提供了更多的靈活性。盡管 Dependabot 仍然是一個安全的默認選擇，并且能夠更方便地與 GitHub 集成，但我們建議評估 Renovate，看看它是否可以進一步減輕開發人員手動維護應用生態系統安全的負擔。63.Terrascan試驗T

94、errascan 是一個用于基礎設施即代碼（IaC）的靜態代碼分析器，旨在云原生基礎設施部署之前檢測安全漏洞和合規問題。它支持對 Terraform，Kubernetes（JSON/YAML），Helm，AWS CloudFormation，Azure Resource Manager，Dockerfiles 和 GitHub 進行掃描。默認策略包支持所有主流的云供應商，GitHub，Docker 和 Kubernetes.我們團隊在本地使用 Terrascan 作為預提交鉤子（pre-commit hook）并在 CI 流水線中集成 Terrascan 來檢測 laC 漏洞和違規行為。64.

95、Velero試驗Velero 是一個用于備份和恢復 Kubernetes 資源和持久卷的開源工具。它通過啟用按需和計劃備份，簡化了災難恢復和集群遷移。Velero 還能更精細地控制哪些資源被備份，以及相關的備份/恢復流程。我們很贊賞它的易用性，以及它依賴的是 Kubernetes API 而非更低層次的 etcd 等。65.aider評估aider 是一款開源的 AI 輔助編碼工具。與該領域的許多開源工具一樣，aider 并不直接與 IDE 集成，而是以 CLI 的形式在終端啟動。目前許多輔助編碼工具只能讀取代碼，或者一次只能更改一個文件，而 aider 的有趣之處在于，它提供了一個聊天界面，

96、并且有寫權限來對多個文件的代碼庫進行訪問。這使得 aider 可以幫助實現跨越多個文件的概念（例如，在 HTML 中添加定位器，然后在功能測試中使用它們”），并在代碼庫中創建新的文件和文件夾結構（例如，創建一個與 X 文件夾中的組件類似的新組件）。由于 aider 是開源而非托管產品，因此需要提供 OpenAI 或 Azure OpenAI API 密鑰才能使用。一方面，因為是按使用量計費，這非常適合輕度使用；但另一方面，aider 在與 AI API 交互時似乎很“健談”，因此使用時要注意請求開銷和費用限制。66.Akvorado評估Akvorado 是一個開源的網絡監控和分析工具。它可以捕

97、獲網絡流量，支持 Netflow/IPFIX 和 sFlow 協議，為其添加接口名稱和地理信息，然后將更新后的流量保存在 ClickHouse 中供未來分析使用。雖然 OpenTelemetry工具 Thoughtworks,Inc.All Rights Reserved.30在觀測應用層流量方面越來越受歡迎，但我們通常會遇到在網絡層面很難發現和解決的挑戰。在這種情況下，像 Akvorado 這樣的工具非常有用，它可以幫助你分析網絡拓撲中各種設備之間的網絡流量。67.百川 2評估百川 2 是新一代開源大型語言模型。它采用了 2.6 萬億 Tokens 的高質量語料進行訓練，在中文、英文和多語言

98、基準測試上表現出色。值得注意的是百川在醫療和法律等領域特定的數據集進行了針對性訓練，這讓我們在相關垂直領域會優先考慮它。68.Cargo Lambda評估Rust 的高效和性能很適合用于無服務器計算，再考慮到它還有函數無需運行時的優勢，這些都使得它能快速啟動工作。但是使用 Rust 開發 lambda 函數的體驗此前并不好，而這一情況被 Cargo Lambda 的出現改變了。作為 cargo 的子命令，它能集成到典型的 Rust 工作流中并且能允許你在開發機上運行和測試 AWS Lambda 函數而無需借助 Docker、虛擬機，或者其他工具。使用 Zig 工具鏈，Cargo Lambda

99、可以在多種不同操作系統中的 Linux 沙盒中交叉編譯并用于 AWS Lambda，這套工具鏈支持 ARM 和 Intel 作為目標架構。69.Codium AI評估在 AI 編程助手持續涌現的過程中，相較于孵化大而全的工具，一些產品選擇聚焦于某些領域。Codium AI 正是如此，它聚焦于使用 AI 生成代碼測試?？梢杂糜谒芯幊陶Z言，但是對常用技術棧如 JavaScript 和 Python 提供了更進階的支持。我們格外中意這個工具，因為它不只向開發者提供測試代碼，同時還能對場景提供用于評審的自然語言描述。這能使開發者理解測試用例背后的用意，幫助開發者選擇哪些要放入代碼庫。如果想要進一步提

100、高對特定代碼庫和測試用例生成的測試質量，用戶可以提供測試示例和一些提示，幫助 AI 獲取更多高質量的信息。70.Continue評估Continue 是一種用于 VS Code 和 JetBrains IDEs 的開源 AutoPilot 工具。我們非常喜歡它，因為它通過與 IDE 的直接集成，消除了從聊天界面復制/粘貼到大型語言模型的痛苦。它支持多個商業和開源 模型，并且它能夠幫助嘗試不同的大語言模型 提供商，包括 自托管的大語言模型。甚至可以在 沒有網絡連接 時運行 Continue。71.Fern Docs評估目前被廣泛使用的 REST APIs 的一個特點是它們的合約會被徹底地記錄在案

101、。開發者更傾向于采納和使用那些以結構化、有組織的方式準確描述其行為和語法的 API。隨著合約的發展，保持這些文檔的更新可能既耗時又工具 Thoughtworks,Inc.All Rights Reserved.31容易被忽視。Fern Docs 通過減少編寫和維護 API 文檔的勞動強度來幫助解決這個問題。Fern 可以自動從規范文件生成一個具有吸引力、可用文檔的網站，這個文件能與 API 代碼一起版本化。我們對這個產品的初步印象是積極的，不過 Fern 要求用戶在一個專有配置文件中維護 API 信息，盡管它提供了一種將 OpenAPI 規范轉換為其自己的配置格式的方法，但我們更期待一個能夠直

102、接從帶注釋的源代碼生成文檔的工具。72.Granted評估鑒于組織在 AWS 環境中常常采用多賬戶策略，工程師經常需要在短時間內切換多個賬戶。而 Granted 作為一個命令行工具，簡化了同時在瀏覽器中打開多個賬戶的操作，從而使賬戶切換變得更加流暢。它利用瀏覽器的原生功能來隔離多個身份，例如 Firefox 的 多賬戶容器 和 Chromium 的配置文件。如果指定了特定服務（如 S3）作為參數，Granted 會打開該服務的登錄頁面。目前，Granted 僅支持 AWS。值得注意的是，它將 AWS SSO 的臨時憑證安全地存儲在密鑰鏈中，而不是以明文形式存儲在磁盤上。73.LinearB評估

103、LinearB 是一個旨在為工程領導者提供數據驅動洞察以實現持續改進的平臺。它主要在三個關鍵領域發揮作用：基準測試、工作流自動化和投資。我們在使用 LinearB 的度量工具時發現，它有助于支持持續改進。我們的一個團隊利用該平臺跟蹤工程度量、識別和討論改進機會，并根據數據定義可行的步驟，從而取得了可衡量的進展。我們很高興看到這與 LinearB 的核心價值主張相一致：基準、自動化和改進。LinearB 與 GitHub、GitLab、Bitbucket 和 Jira 集成。它提供了一套全面的預配置工程度量，重點關注 DORA 度量（部署頻率、交付周期、變更失敗率和恢復時間）。作為 DORA 研

104、究定義的四個關鍵度量的堅定支持者，我們欣賞 LinearB 在度量對軟件交付效能真正重要的維度的重視。一直以來，收集 DORA 特定度量都是一個挑戰。許多團隊不得不借助復雜的 CD 管道儀器、自定義儀表板或依賴手動流程。盡管我們的體驗僅限于一個團隊，但 LinearB 似乎是工程度量收集和跟蹤以及培養數據驅動持續改進方法的一個引人注目的替代品。74.LLaVA評估LLaVA（Large Language and Vision Assistant）是一個開源的大型多模態模型，它結合了視覺編碼器和大語言模型，用于通用視覺和語言理解。LLaVA 在遵循指令方面的強大能力，使其成為多模態人工智能模型中

105、的有力競爭者。最新版本，LLaVA-NeXT，能進一步提升問答能力。在開源的語言和視覺輔助模型中，與 GPT-4 Vision相比，LLaVA 是一個很有前景的選擇。我們的團隊一直在使用它進行視覺問題解答。75.Marimo評估Marimo 通過優先考慮復用性和交互性，為 python notebook 提供了新的體驗。它解決了傳統 notebook 如Jupyter 中隱藏狀態（hidden state）的挑戰，該問題可能導致不可預料的結果并阻礙可復用性。Marimo 通過工具 Thoughtworks,Inc.All Rights Reserved.32工具將 notbook 存儲為無隱藏

106、狀態的純 python 文件和基于依賴關系（當變量改變時，所有受影響的 cell 會自動運行）的確定性執行順序來解決這個問題。Marimo 還使用了類似的可以將 cell 值的改變傳遞給依賴于該 cell 的交互式 UI 元。它可以被部署為網頁 app，也可以用于展示成果和進行原型設計。雖然我們對 Marimo 的潛力，尤其是數據探索和分析目標上的再現性潛力感到興奮，我們依然謹慎對待生產化的筆記本。76.Mixtral評估Mixtral 是 Mistral 發布的開放權重大語言模型家族的一部分，它采用了稀疏混合專家架構。這個模型家族以 7B 和 8x7B 參數大小的形式，提供原始預訓練和微調版

107、本。其大小、開放權重特性、基準測試中的性能以及 32,000 個 token 的上下文長度，使其成為自托管大語言模型中一個非常耀眼的選擇。需要注意的是，這些開放權重模型并沒有針對安全性進行優化調整，用戶需要根據自己的用例進行精細調整。我們在開發與特定印度法律任務相關的數據上訓練的精調 Mistral 7B 模型 Aalap 方面有一定經驗，該模型在有限成本的基礎上表現相當好。77.NeMo Guardrails評估NeMo Guardrails 是 NVIDIA 的一個易用開源的工具包，它可以使開發人員在會話應用的大語言模型上實現一套防護措施。盡管大語言模型在構建交互式體驗上有巨大的潛力，但他

108、們在事實準確性、偏見和潛在的濫用方面上存在一些固有的局限性，這使得我們需要采取一些必要的保護措施。Guardrails 提供了一個有前景的方法來確保大語言模型的責任性和可信性。盡管當談到大語言模型的保護措施時都會有多種選擇，但是我們團隊發現 NeMo Guardrails 尤其有用，因為它支持可編程的規則和運行時的集成，并且可以應用到現有的大語言模型的應用上，而不需要大量的代碼修改。78.Ollama評估Ollama 是一個在本機上運行并管理大語言模型的工具。我們之前討論過自托管大語言模型我們很高興這個生態逐漸成熟，產生了像 Ollama 的工具。Ollama 支持多種 流行的模型 的下載和本

109、地運行包括 LLaMA-2，CodeLLaMA，Falcon 和 Mistral。一經下載，你可以通過命令行、接口或者開發組件與模型交互執行任務。我們正在評估 Ollama，目前看起來不錯，能通過在本機運行大語言模型提升開發者體驗。79.OpenTofu評估OpenTofu 是對 Terraform 的一個分支，作為對 HashiCorp 最近模糊不清的許可證更改的回應。它是開源的，并已被 Linux Foundation 接受。它得到了包括第三方供應商在內的幾個組織的支持。當前版本與 Terraform 的最后一個開源版本兼容。1.7 版新增了客戶端加密功能。OpenTofu 項目的未來尚不

110、明確，包括它將如何緊密支持 Terraform 未來版本的兼容性，它能否得到當前支持者的長期支持也是一個未知項。我們建議持續關注它，但要謹慎使用。如果你們團隊有非常強的風險管理能力，可以嘗試使用，或許還能為代碼庫作出一些貢獻。Thoughtworks,Inc.All Rights Reserved.33工具80.QAnything評估大語言模型（LLMs）和檢索增強生成（RAG）技術極大地提高了我們整合和提取信息的能力。我們看到越來越多的工具利用了這一點，QAnything 就是其中之一。QAnything 是一個問答界面的知識管理引擎，能夠從包括 PDF、DOCX、PPTX、XLSX 和 M

111、D 文件等在內的多種文件格式中總結和提取信息。出于數據安全考慮，QAnything 還支持離線安裝。我們的一些團隊使用 QAnything 來構建他們的團隊知識庫。在具有更深行業深度的 GenAI 場景中（例如為投資報告生成摘要），我們也嘗試使用這個工具進行概念驗證，以在構建真正的產品之前展示 LLMs 和 RAG 的潛力。81.System Initiative評估近年來，幾乎沒有新興工具能挑戰 Terraform 作為基礎設施即代碼工具的主導地位。盡管出現了 Pulumi、CDK 以及最近的 Wing 等替代方案，但 Terraform 的模塊化、聲明式范式已被證明是最持久流傳的。事實上，

112、所有這些方法都有一個共同的目標，即模塊化代碼創建單一的基礎設施。System Initiative 是一款全新的、實驗性的工具，代表了 DevOps 工作的一個新方向?？梢詫?System Initiative 視為基礎設施的數字孿生。對 System Initiative 狀態的交互式更改會導致相應的變更集，可以應用于基礎設施本身。同樣，基礎設施的變更也會反映在 System Initiative 狀態中。這種方法的一個巨大優勢體現在，它為應用部署和可觀測性等事務創造的協作環境。工程師通過具有整個環境圖形表示的用戶界面，與 System Initiative 進行交互。除了管理云基礎設施，您

113、還可以使用該工具來管理容器、腳本、工具等。盡管我們通常對這類 GUI 工具持懷疑態度，但 System Initiative 可以通過 TypeScript 代碼擴展來處理新資產或執行策略。我們非常喜歡這個工具中所體現的創造性思維，并希望它能鼓勵其他人突破基礎設施即代碼方法的現狀。System Initiative 是免費和開源的，基于 Apache 2.0 許可，目前處于公開測試階段。維護者自己還不建議將該工具用于生產環境，但我們認為它值得在當前狀態下檢查，體驗一種完全不同的 DevOps 工具方法。82.Tetragon評估Tetragon 是一個基于 eBPF 的開源安全可觀測性和運行時

114、強制執行工具。我們一段時間前在 Radar 中提到了 Falco，用于檢測安全威脅。Tetragon 通過利用 eBPF 在 Linux 內核中在運行時 執行安全策略，實現了不僅限于威脅檢測的能力。你可以將 Tetragon 作為一個獨立工具在裸機環境中使用，也可以在 Kubernetes 環境中 使用。83.Winglang評估我們正在基礎設施即代碼（IaC）領域看到許多新動態，像 Winglang 這樣的工具正在出現。Winglang 采取了一種不同的方法來定義基礎設施和運行時行為。它提供了高級抽象，覆蓋了由 CloudFormation、Terraform、Pulumi 和 Kubern

115、etes 等工具提供的平臺特定功能。使用 Winglang，你可以編寫在編譯時運行的代碼以生成基礎設施配置，然后編寫在運行時執行的代碼以進行應用程序行為。它提供了一種在本地運行的模擬模式，并集成了測試框架。我們正在關注這個有趣的工具，它可能預示了 IaC 未來發展方向。Thoughtworks,Inc.All Rights Reserved.語言和框架采納 試驗84.Astro85.DataComPy86.Pinia87.Ray評估88.安卓適應性89.Concrete ML90.Crabviz91.Crux92.Databricks Asset Bundles93.Electric94.Li

116、teLLM95.LLaMA-Factory96.MLX97.Mojo98.Otter99.Pkl100.Rust for UI101.vLLM102.Voyager103.WGPU104.Zig暫緩105.LangChain18824293031323334353637383940414243262345679151617101112131444474950656667686970717273747576777879808182835152545953565861626364858889909192939495969798991001011021031048687192122202825272

117、3841051454648555760暫緩暫緩評估評估試驗試驗采納采納新的挪進/挪出沒有變化 Thoughtworks,Inc.All Rights Reserved.3584.Astro試驗Astro 框架在社區中越來越受歡迎。我們的團隊已經使用 Astro 構建了諸如博客和營銷網站之類的內容驅動型網站。Astro 是一個多頁面應用程序框架，它在服務器上渲染 HTML 并最小化通過網絡發送的 JavaScript。我們認為不錯的一點是，盡管 Astro 鼓勵僅發送 HTML，但它支持在適當的情況下選擇性地使用您選擇的前端 JavaScript 框架編寫的活動組件。它通過其島嶼架構實現這一點。

118、島嶼是單頁內的交互區域，在這里所需的 JavaScript 僅在需要時才被下載。通過這種方式，網站的大部分區域被轉換為快速的靜態 HTML，而 JavaScript 部分則優化為并行加載。我們的團隊既喜歡其頁面渲染性能，也喜歡其構建速度。Astro 組件語法是 HTML 的簡單擴展，學習曲線相當平緩。85.DataComPy試驗對數據幀進行比較是數據工程中的常見任務，常用于確保兩個數據轉換方法間沒有顯著的偏差或不一致。DataComPy 是一個用于比較 pandas，Spark 或其他格式 DataFrame 的工具。這個庫不僅能比較 DataFrame 的一致性，還能在行和列上對不一致的地方

119、給出細致的洞見。DataComPy 還可以指定忽略掉無需展示的數值絕對/相對比較和已知差異。我們的一些團隊將它用于了冒煙測試組件中，他們發現它能高效比對大數據量多字段的 DataFrame，與此同時它給出的報告也易于理解和應對。86.Pinia試驗Pinia 是一個在 Vue.js 中使用的存儲庫和狀態管理框架。它使用聲明性語法并提供了自己的狀態管理 API。與Vuex 相比，Pinia 提供了一個更簡單的 API，簡化了使用流程，提供了組合式 API，并且在與 TypeScript 一起使用時具有可靠的類型推斷支持。Vue.js 團隊認可 Pinia 作為 Vuex 的可靠替代品，目前它是

120、Vue.js 的官方狀態管理庫?？偟膩碚f，我們認為 Pinia 的簡單性和易用性是非常不錯的。87.Ray試驗機器學習（ML）的工作負載正在變得越來越計算密集型。盡管用筆記本電腦開發訓練模型很便利，但這樣的單節點開發環境很難適應擴展需求。Ray AI 和 Python 代碼從筆記本電腦擴展到集群的統一框架。它本質上是一個封裝良好的分布式計算框架，集成了一系列 AI 庫以簡化 ML 的工作。通過與其他框架（例如，PyTorch 和TensorFlow 的集成，它可以用于構建大規模 ML 平臺。像 OpenAI 和字節跳動這樣的公司大量使用 Ray 進行模型訓練和推理。我們還使用它的 AI 庫幫助

121、我們的項目進行分布式訓練和超參數調優。我們推薦你在構建可擴展的 ML 項目時嘗試使用 Ray。88.安卓適應性評估有些移動應用或者游戲非常消耗資源，他們可以在幾分鐘內導致散熱過載。在這種情況下，設備會降低 CPU 和 GPU 的頻率以降低溫度，但游戲幀率也會隨之降低。當散熱情況有所改善時，設備的幀率會回升。如此循環往語言和框架 Thoughtworks,Inc.All Rights Reserved.36復，軟件會變得非常不穩定。Android Adaptability 是一套允許移動程序開發者根據動態的設備性能和散熱情況進行調校的新類庫集。安卓動態性能框架（ADPF）集成了提供設備熱量信息的

122、 Thermal API、幫助安卓系統選擇 CPU 的最佳運行點以及核心配置的 Hint API。Unity 的自適應性能包也同時支持這兩種 API，使用 Unity 進行開發的團隊應該會覺得這很有幫助。89.Concrete ML評估在此之前，我們曾經標記過允許在加密過的數據上進行計算的同態加密技術。Concrete MLl 就是這樣一個允許在隱私保護的環境下進行機器學習的開源工具。作為一個基于 Concrete 構建的工具，它幫助數據科學家們簡化了完全同態加密（FHE）的使用，幫助他們將機器學習的模型自動轉化為同態加密過的數據。此外，Concrete ML的內置模型中還有和他們的機器學習算

123、法庫幾乎相同的API。你也可以通過Concrete ML的轉換API將PyTorch 網絡進行完全同態加密。然而，需要注意的是，若在沒有調校過的硬件 中使用 Concrete ML 會導致完全同態加密的速度變慢。90.Crabviz評估Crabviz 是一個用于創建調用圖的 Visual Studio Code 插件。這些圖表是交互式的，這在使用中等規模的代碼庫（例如微服務）時起到了很大的作用。它們按文件分組顯示類型、方法、函數和接口，并顯示函數調用關系和接口實現關系。因為 Crabviz 基于語言服務器協議，只要安裝了相應的語言服務器，就可以支持任意數量的語言。雖然這也意味著 Crabviz

124、 僅限于靜態代碼分析，可能不足以滿足某些用例。該插件是用 Rust 編寫的，可在 Visual Studio Code Marketplace 上獲取。91.Crux評估Crux 是一個用 Rust 編寫的開源跨平臺應用開發框架。受到 Elm 架構的啟發，Crux 將業務邏輯代碼作為核心，UI 層則使用了原生框架（如 SwiftUI、Jetpack Compose 以及 React/Vue），或者是基于 WebAssembly 的框架（如 Yew）。通過 Crux，你可以在 Rust 中編寫無副作用的行為代碼，并在 iOS、Android 和網頁中共享。92.Databricks Asset

125、Bundles評估Databricks 最近發布了 Databricks Asset Bundles（DABs）的 公開預覽版，它包含在 Databricks CLI 0.205 及更高版本中，正成為打包 Databricks 資源進行源代碼控制、測試和部署的官方推薦方式。DABs 在我們的團隊中逐漸取代了 dbx。DABs 支持將工作流、作業和任務的配置以及要在這些任務中執行的代碼打包成一個可以部署到多個環境的捆綁包。它附帶了常見資產類型的模板，并支持自定義模板。雖然 DABs 包含筆記本模板并支持將它們部署到生產環境，但我們仍然建議不要將 筆記本用于生產環境，而是鼓勵有意地編寫生產代碼，并

126、采用支持此類工作負載的可維護性、彈性和可擴展性的工程實踐。語言和框架 Thoughtworks,Inc.All Rights Reserved.3793.Electric評估Electric 是一種用于移動和 Web 應用程序的本地優先同步框架。本地優先是一種開發范式，其中應用程序代碼直接與嵌入式本地數據庫對話，并通過雙活數據庫復制到中央數據庫，在后臺進行數據同步。使用 Electric，您可以將 SQLite 作為本地嵌入式選項，并將 PostgreSQL 作為中央存儲。盡管本地優先極大地改善了用戶體驗，但它并非沒有挑戰，CRDT 的發明者們已經在 Electric 框架上努力解決這些問題，

127、以減輕困擾。94.LiteLLM評估LiteLLM 是一個庫，通過 OpenAI API 格式 的標準化交互實現與各種大語言模型（LLM）提供商的 API 的無縫集成。它廣泛支持各類提供商和模型，并具備一個用于完成、嵌入和圖像生成功能的統一界面。LiteLLM 通過將輸入轉換為匹配每個提供商特定端點要求的方式，簡化了集成。在當前環境下，這特別有價值，因為缺乏標準化的 LLM 提供商 API 規范會導致項目中包含多個 LLM。我們的團隊已經利用 LiteLLM 在 LLM 應用中更換底層模型，解決了一個重大的集成挑戰。然而，需要認識到，它對相同提示的模型有不同響應，這表明僅僅一致的調用方法可能不

128、足以完全優化完成性能。請注意，LiteLLM 還有其他一些特性，如 代理服務器，這些不在本次討論范圍內。95.LLaMA-Factory評估我們一如既往地提醒大家，非必要情況下，不要著急對大語言模型進行微調 這將增加顯著的成本和專家資源負擔。在必須微調的情況下，我們推薦 LLaMA-Factory。它是一個開源的、易于使用的 LLMs 微調和訓練框架。支持 LLaMA、BLOOM、Mistral、Baichuan、Qwen 和 ChatGLM，它使微調等復雜概念相對容易理解。我們的團隊成功地使用了 LLaMA-Factory 的 LoRA 調優來訓練 LLaMA 7B 模型。如果您需要進行微調

129、，這個框架是值得評估的。96.MLX評估MLX 是一個開源的數組框架，專為在蘋果芯片上進行高效靈活的機器學習而設計。它使得數據科學家和機器學習工程師可以訪問集成的 GPU，并在這個基礎上選擇最適合其需求的硬件。MLX 的設計靈感來自于諸如 NumPy、PyTorch 和 Jax 這樣的框架。MLX 的特殊之處在于統一內存模型，它消除了 CPU 和 GPU 之間數據傳輸的成本，從而實現更高的執行速度。這個特性使得在諸如 iPhone 等設備上運行模型成為可能，為設備端的 AI 應用開辟了巨大的機會空間。盡管這是一個小眾領域，但這個框架值得機器學習開發者社區嘗試。語言和框架 Thoughtwork

130、s,Inc.All Rights Reserved.3897.Mojo評估Mojo 是一種新的以人工智能為先的編程語言。它旨在通過將 Python 語法和生態系統與系統編程和元編程特性相結合，縮小研究和生產之間的差距。它是第一種利用新的 MLIR 編譯器后端的語言，擁有零成本抽象、自動調優、及早銷毀、尾調用優化和更好的單指令/多數據（SIMD）工學等炫酷功能。我們非常喜歡 Mojo，并鼓勵您嘗試一下。Mojo SDK 目前適用于 Ubuntu 和 macOS 操作系統。98.Otter評估Otter 是一個在 Go 語言中非競爭式的緩存庫。雖然 Go 語言有幾個類似的庫，但我們想要強調 Ott

131、er 有兩個原因：它具有出色的吞吐量并且能夠巧妙地實現 S3-FIFO 算法，以獲得良好的緩存命中率。Otter 還支持泛型，因此用戶可以將任何可比較的類型用作鍵，并將任何類型用作值。99.Pkl評估Pkl 是最初在蘋果公司內部使用、現在已開源的配置語言和工具。Pkl 的關鍵特性是其類型和驗證系統，允許在部署之前捕獲配置錯誤。它生成 JSON、.plist、YAML 和.properties 文件，并擁有廣泛的 IDE 和語言集成，包括代碼生成。100.Rust for UI評估Rust 的影響力與日俱增，很多最近出現的構建工具和命令行工具都是由 Rust 編寫的。我們現在觀察到 Rust 有

132、移植到 UI 開發領域的趨勢。大部分偏向于在前后端使用統一代碼語言的開發團隊會選擇 JavaScript 或者 TypeScript 作為后端語言。然而，開發者現在也可以通過 WebAssembly 在瀏覽器里使用 Rust 代碼，而這正在變得越來越常見。另外，像 Leptos 和 sauron 這樣的框架會更關注在網頁應用開發上，同時 Dioxus 還有其他的一些框架在網頁應用開發之外還提供了跨平臺桌面以及移動應用開發的支持。101.vLLM評估vLLM 是一個具有高吞吐量和高效內存的大語言模型（LLM）推理和服務引擎，其特別有效的原因在于它可以對傳入請求進行連續批處理。它支持幾種部署選項，

133、包括使用 Ray 運行時進行分布式張量并行推理和服務部署，在云中使用 SkyPilot、NVIDIA Triton、Docker 和 LangChain 進行部署。我們團隊的經驗是在本地虛擬機中運行基于 docker 的 vLLM worker，集成了與 OpenAI 兼容的 API 服務器，并在此基礎上被一系列應用所利用（包括用于編碼輔助以及聊天機器人的 IDE 插件）。團隊對此反饋良好。我們的團隊利用 vLLM 運行諸如CodeLlama 70B、CodeLlama 7B 和 Mixtral 等模型。引擎的另一個顯著特點是其可擴展能力：只需進行一些配置更改，就可以從運行 7B 模型轉換為

134、70B 模型。如果您希望將 LLMs 投入生產，那么 vLLM 值得進一步探索。語言和框架 Thoughtworks,Inc.All Rights Reserved.39102.Voyager評估Voyager 是為 Android 的 Jetpack Compose 構建的導航庫。它支持多種導航類型，包括線性、底部表單、標簽和嵌套，其屏幕模型與流行框架如 Koin 和 Hilt 集成。在多平臺項目中使用 Jetpack Compose 時，Voyager 是實現跨所有支持平臺的常見導航模式的優秀選擇。近期，Voyager 的開發又重新活躍起來，并在 2023 年 12 月交付了 1.0 版本

135、。103.WGPU評估wgpu 是一個基于 WebGPU API 的 Rust 圖形庫，它以能夠高效處理 GPU 上通用圖形和計算任務的能力而聞名。wgpu 旨在填補由于淘汰舊的圖形標準（如 OpenGL 和 WebGL）而留下的空白。它引入了一種現代的圖形開發方法，既適用于本地應用程序，也適用于基于 Web 的項目。它與 WebAssembly 的集成進一步使得圖形和計算應用程序能夠在瀏覽器中運行。wgpu 的出現是一種進步，使高級圖形編程對 Web 開發人員更加可訪問，應用范圍更廣泛，從游戲到創建復雜的 Web 動畫，將 wgpu 定位為一種令人振奮的技術。104.Zig評估Zig 是一種

136、新的編程語言，它與 C 語言有許多共同點，但具有更強的類型系統、更容易的內存分配以及對命名空間的支持等，此外還有許多其他特性。Zig 的目標是提供一個非常簡單的語言，具有直接明了的編譯過程，最小化副作用，并提供可預測、易于追蹤的執行。Zig 還簡化了訪問 LLVM 的跨平臺編譯能力。我們的一些開發者發現這個特性非常有價值，他們甚至在不編寫 Zig 代碼的情況下，也能使用 Zig 作為交叉編譯器。我們看到行業中的團隊使用 Zig 幫助構建 C/C+工具鏈。對于那些正在考慮或已經使用 C 的應用程序，Zig 是一種值得探索的新穎語言。105.LangChain暫緩在上一期 Radar 中，我們提到

137、了一些關于 LangChain 出現的批評言論。自那以后，我們愈發對其充滿警惕。雖然這個框架為構建大語言模型應用提供了一套強大的功能，但我們發現它使用起來很困難且過于復雜。LangChain 在這個領域早期獲得了人氣和注意力，這使得它成為了許多人的默認選擇。然而，隨著 LangChain 試圖發展并快速跟進最新變化，開發者越來越難以跟上這些概念和模式的變更。我們還發現其存在 API 設計不一致且冗長的情況。因此，它經常會掩蓋底層實際發生的情況，使得開發者難以理解和控制 LLMs 及其周圍的各種模式在背后實際是如何工作的。我們將 LangChain 移動到了“暫緩”環，以反映這一點。在我們的許多

138、用例中，我們發現使用更輕量的的專門框架進行實現就足夠了。根據用例，你還可以考慮其他框架，如 Semantic Kernel、Haystack 或 LiteLLM。語言和框架 Thoughtworks,Inc.All Rights Reserved.40想要了解技術雷達最新的新聞和洞見？點擊訂閱，以接收每兩個月一次、來自 Thoughtworks 的技術洞察和未來趨勢探索郵件。Thoughtworks 是一家全球性軟件及技術咨詢公司，集戰略、設計和工程技術咨詢服務于一體，致力于推動數字創新。我們在 19 個國家/地區的 48 個辦公室擁有超過 10,500 名員工。在過去的 30 年里，我們為全球各地的眾多合作伙伴傾力服務，與客戶一起創造了非凡的影響力，幫助他們以技術為優勢解決復雜的業務問題?，F在訂閱