重構第一版和第二版之間變更的簡短摘要

將巨石應用程式拆分為較小的服務時，最困難的部分實際上是拆分儲存在巨石應用程式資料庫中的資料。若要萃取資料豐富的服務，請務必遵循一系列步驟，這些步驟會隨時保留資料的單一寫入副本。步驟從在現有的巨石應用程式中進行邏輯分離開始：將服務行為拆分為獨立的模組，然後將資料分隔到獨立的資料表中。這些元素可以個別移至新的自主服務中。

表面上，敏捷軟體開發的世界一片光明，因為它現在已成為主流。但現實令人擔憂，因為許多做法都是偽敏捷，忽視敏捷的價值觀和原則。我們應專注於三大挑戰：對抗敏捷產業複合體及其強加流程於團隊的習慣、提升技術卓越的重要性，以及圍繞產品（而非專案）組織我們的團隊。儘管有這些問題，社群的強大之處在於其學習和適應能力，解決我們原始宣言作者未曾想像的問題。

一篇快速文章，說明我如何使用 AppleScript 和 Ruby 執行匯出指令碼

我正在完成《重構》一書的新版本。以下是我工作進度的詳細資訊和定期備忘錄。

無伺服器架構是應用程式設計，結合第三方「後端即服務」(BaaS) 服務，和/或包含在「功能即服務」(FaaS) 平台上以受控、臨時容器執行的自訂程式碼。透過使用這些想法，以及類似單頁應用程式等相關想法，此類架構消除了對傳統常駐伺服器元件的大部分需求。無伺服器架構可以大幅降低營運成本、複雜度和工程前期作業時間，但代價是更依賴於供應商依賴關係和相對不成熟的支援服務。

由於巨石系統變得過於龐大而難以處理，許多企業開始將其拆分為微服務架構樣式。這是一趟值得的旅程，但並不容易。我們了解到，要順利完成這項工作，我們需要從一個簡單的服務開始，然後繪製出基於對企業而言重要的垂直功能且容易變動的服務。這些服務一開始應該規模較大，最好不依賴於其餘的巨石應用程式。我們應該確保遷移的每一步都代表整體架構的原子化改進。

敏捷方法已穩固地成為主流，但這種普及並非沒有問題。組織領導者抱怨他們沒有獲得預期的效益。本文提出一個流暢度模型，將有助於您充分發揮敏捷理念。流暢度會經過四個不同的區域演進，每個區域都有其自身的效益、所需的熟練度和關鍵指標。

如今，每個人都在建構「平台」以加速大規模交付數位產品。但是，什麼構成了有效的數位平台？有些組織在嘗試在其現有的共用服務之上建構時會遇到困難，因為他們沒有先解決其組織結構和營運模式。

「測試金字塔」是一個比喻，告訴我們將軟體測試分組到不同粒度的儲存區中。它也提供了一個概念，說明我們應該在這些群組中的每一個群組中有多少測試。儘管測試金字塔的概念已經存在一段時間，但團隊仍然難以適當地將其付諸實踐。本文重新探討測試金字塔的原始概念，並展示如何將其付諸實踐。它展示了您應該在金字塔的不同層級中尋找哪些類型的測試，並提供如何實作這些測試的實用範例。

軟體專案是為軟體開發提供資金和組織的一種常見方式。它們將工作組織成臨時的、僅供建置的團隊，並透過商業案例中預測的特定利益獲得資金。產品模式則使用持久性的、構思-建置-執行團隊來處理持續性的業務問題。產品模式讓團隊可以快速重新定位、縮短端對端循環時間，並透過使用短週期迭代來驗證實際利益，同時維持軟體的架構完整性，以維持其長期效能。

整合測試用於判斷獨立開發的軟體單元在連接彼此時是否運作正常。這個術語即使在軟體產業的模糊標準下也變得模糊不清，因此我在寫作時一直很小心使用它。特別是，許多人假設整合測試的範圍一定很廣，但實際上範圍較窄的測試更有效。