我 2021 年最喜歡的六首新歌

架構不一定要是獨白；由少數集中的人員自上而下傳達。本文描述另一種執行架構的方式；透過對話系列，由分散且賦能的決策制定技術驅動，並由四種學習與調整機制提供支援：決策紀錄、諮詢論壇、團隊來源原則和技術雷達

商業整合工具已問世數十年，但鮮少有整體架構原則說明何時以及如何使用這些工具。在本文中，我主張「購買」決策機制導致我們誇大了此類工具的價值主張，通常會導致強制使用特定整合工具，而非通用語言。我主張此類工具在將整合視為主要連接系統的世界中蓬勃發展，但數位組織已重新構想整合，使其主要在數位功能前放置乾淨介面，強調功能而非系統。最後，我列出現代整合觀點背後的一些關鍵原則，並主張使用通用語言來最佳管理這些原則，將商業整合工具的主要價值主張重新導向簡化戰術實作考量。

我以前的同事 Dave Farley 一直經營一個越來越受歡迎的軟體開發 YouTube 頻道。這是很好的素材，非常符合我的觀點，畢竟他的經驗對我的思考影響很大。我們討論了關於軟體工程當前角色的各種主題，特別關注我目前支援的三個大型寫作專案：資料網格、分散式系統模式和舊系統取代模式。

在每個正常規模的團隊中，將任何類別技術的替代方案選擇限制為三個。這些是：目前明智的預設值、我們正在試驗的選項，以及我們討厭且想要退休的選項。

良好的技術設計決策非常依賴於背景。定期為共同目標攜手合作的團隊能夠定期溝通並快速協商變更。這些團隊展現出強大的力量，並能做出利用該強大力量的技術和設計決策。當我們在較大的組織中縮小範圍時，獨立工作且較少頻繁協作的團隊和部門之間存在越來越弱的力量。了解這些強弱力量的差異，讓我們能夠做出更好的決策，並為每個層級提供更好的指導，讓團隊能更快速地賦能並行動。

整合必要的安全控制和稽核功能，以滿足 DevOps 文化中的合規性要求，可以利用 CI/CD 管線自動化，但在組織擴展時會出現獨特的挑戰。了解所選實作的次要影響和意外後果，是建構有效、安全且可擴充解決方案的關鍵。

發布/展示/詢問是一種分支策略，結合了拉取要求的功能，並具備持續發布變更的能力。變更分為發布（合併到主線而不進行檢閱）、展示（開啟拉取要求進行檢閱，但立即合併到主線）或詢問（在合併前開啟拉取要求進行討論）。

有趣的軟體很少獨立存在。團隊編寫的軟體通常必須與外部系統互動，這些系統可能是函式庫、對外部服務的遠端呼叫、與資料庫的互動，或與檔案的互動。通常會有某種形式的 API 供該外部系統使用，但該 API 通常會從我們軟體的背景中看起來很奇怪。API 可能使用不同的類型、需要奇怪的引數，並以在我們的背景中沒有意義的方式組合欄位。處理此類 API 可以在每次使用時造成令人不快的失配。

閘道器作為與此外來者對抗的單一據點。系統中的任何程式碼都與閘道器介面互動，而閘道器介面設計為使用系統使用的條款運作。接著，閘道器會將此便利的 API 轉譯為外來者提供的 API。

演講一直是我職業生涯的支柱之一。我在世界各地的軟體活動中發表過主題演講。其中一些演講在 YouTube 上的觀看次數達到數萬，甚至數十萬。但我一直很討厭演講，因此決定不再演講。

關於測試組合應為金字塔形或更類似蜂巢形，存在爭論。我對此爭論的第二個最大問題是，由於人們不清楚單元測試和整合測試之間的差異，因此它變得不透明。

開發人員生產力平台日益被視為管理工程團隊認知負載並縮短新功能上市時間的方法。然而，組織需要培養一些基本能力，才能成功執行平台策略。平台團隊需要將平台視為軟體產品，需要與其使用者對話、注意可靠的運作，並建立健全的團隊環境。

如何使用 R 繪製柔和的義大利麵圖，包括分面。

通常需要存取某些屬性的歷史值。但有時此歷史本身需要根據追溯更新進行修改。雙時態歷史將時間視為兩個面向：實際歷史記錄了在資訊傳遞完美的情況下應有的歷史，而記錄歷史則記錄了我們對歷史的認知如何改變。

當人們想到程式碼檢閱時，通常會想到開發團隊工作流程中明確的步驟。現今，在Pull Request上執行的整合前檢閱是最常見的程式碼檢閱機制，以致於許多人愚蠢地認為不使用 pull request 會消除所有進行程式碼檢閱的機會。如此狹隘的程式碼檢閱觀點不僅忽略了許多明確的檢閱機制，更重要的是忽視了可能是最強大的程式碼檢閱技術，也就是由整個團隊執行的持續改進。

Pull Request 是由 github 推廣的機制，用於協助促進工作的合併，特別是在開源專案的背景下。貢獻者在中央儲存庫的分支（複製）中處理其貢獻。一旦他們的貢獻完成，他們就會建立一個 pull request，以通知中央儲存庫的所有者，他們的作品已準備好合併到主線中。工具支援並鼓勵在接受請求之前對貢獻進行程式碼檢閱。Pull request 已廣泛用於軟體開發，但批評者擔心會增加整合摩擦，這可能會阻礙持續整合。

技術不斷變得更智慧且更強大。我常常觀察到，當這些技術被導入後，組織的生產力並未提升，反而下降。這是因為技術增加了開發人員的複雜性和認知負擔，降低了他們的效率。在本文中，作為一系列文章的第一篇，我將介紹一個最大化開發人員效率的架構。透過研究，我已找出關鍵的開發人員回饋迴路，包括開發人員每天執行 200 次的微型回饋迴路。這些迴路應進行最佳化，以便對開發人員來說快速、簡單且有影響力。我將探討一些組織如何使用這些回饋迴路來提升整體效率和生產力。

最近的事件突顯出我們需要採取嚴肅措施來反制破壞民主的謊言。