遺留係統重建實戰 pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[英] 剋裏斯·伯查爾（Chris Birchall） 著，張喻，張耀丹，禚嫻靜 譯

圖書標籤:

• 遺留係統
• 係統重建
• 軟件重構
• 技術債務
• 架構演進
• Java
• 微服務
• 雲原生
• 數字化轉型
• 案例分析

齣版社： 人民郵電齣版社

ISBN：9787115465856

版次：1

商品編碼：12185555

品牌：異步圖書

包裝：平裝

開本：16開

齣版時間：2017-10-01

用紙：膠版紙

頁數：180

正文語種：中文

編輯推薦

作為開發人員，你可能會從另一個團隊接手一個項目，而且該項目是基於現有代碼庫的，擁有很多設計模式、使用假設、基礎設施和工具。幸運的是，有一些方法可以為遺留項目注入新的活力，這樣你就可以維護、改進和擴展它們，而不必顧及它們的局限性。

這是一本以經驗為主導的指南，能使遺留軟件項目脫胎換骨。它涵蓋瞭重構、質量度量學、工具鏈和工作流、持續集成、基礎設施自動化以及組織文化等內容。在技術層麵，讀者將學習如何給代碼模塊化引進依賴注入，如何定量地衡量軟件質量，以及如何實現基礎設施的自動化。在策略層麵，讀者將能學到的實踐有：軟件是應該重寫還是應該重構，團隊的組織架構應該是什麼樣的，以及如何讓管理層意識到軟件質量的重要性。本書的核心議題包括解析和模塊化棘手的代碼結構、集成和自動化測試、替換過時的構建係統，以及用Vagrant和Ansible 之類的工具實現基礎設施自動化。

本書主要內容
● 重構遺留代碼庫。
● 持續審查和持續集成。
● 遺留基礎設施的自動化。
● 給老代碼加新測試。
● 單體應用的模塊化。

本書麵嚮的讀者對象是熟悉麵嚮對象語言（如Java 或C#）的開發人員和團隊領導。

內容簡介

正如本書作者所言，大多數開發人員的主要時間都是花費在與現有的軟件打交道上，而不是編寫全新的應用程序。相信開發人員或多或少都遇到過與遺留係統相關的問題或者睏惑，本書緻力於幫開發人員迴答這些問題，更重要的是，幫開發人員避免把自己當前開發的係統變成彆人將來要麵臨的遺留問題。

本書篇幅不長，但涵蓋的內容很廣，例證豐富，有大量的示例代碼（主要使用Java或C#編寫），深入淺齣地介紹瞭工作在遺留係統中會遇到的各種問題及應對方法。書中不僅包含技術性的內容—如何選擇構建項目的工具，如何自動化構建基礎設施，如何決定並進行重構或重寫等，也包含非技術性的內容—應該建設什麼樣的團隊文化，如何引入代碼評審等活動，如何進行團隊知識的傳播、改進溝通方式等。

作者簡介

作者簡介
Chris Birchall 是倫敦《衛報》的高-級開發工程師，緻力於為網站提供支持的後颱服務。此前，他做過很多不同的項目，包括日本醫療門戶網站、高性能日誌管理軟件、自然語言分析工具和許多移動網站。他擁有劍橋大學計算機科學專業的學士學位。

譯者簡介
張喻，ThoughtWorks谘詢師，熱愛技術，熱衷編程。目前主要從事後端API的開發、部署、維護等相關工作，在整潔代碼、敏捷實踐和軟件開發高效團隊方麵有豐富的理論和實踐經驗。

張耀丹，ThoughtWorks谘詢師，曾長期參與大型遺留係統的開發與改進，在Java服務器端技術、大型係統架構演進、微服務轉型、DevOps和雲計算方麵有豐富的經驗。

禚嫻靜，ThoughtWorks谘詢師，樂於知識分享與傳播。擁有多年企業和互聯網應用的開發實戰經驗，專注於敏捷實踐、軟件架構和持續交付領域，在.NET技術棧和微服務架構演化等方麵有豐富的積纍。

目錄

目錄



第一部分　開始
第1章　瞭解遺留項目中的挑戰 3
1．1 遺留項目的定義 3
1．1．1 遺留項目的特徵 4
1．1．2 規則的例外 5
1．2 遺留代碼 6
1．2．1 沒有測試和無法測試的代碼 6
1．2．2 不靈活的代碼 8
1．2．3 被技術債務拖纍的代碼 8
1．3 遺留基礎設施 9
1．3．1 開發環境 10
1．3．2 過時的依賴 10
1．3．3 異構環境 11
1．4 遺留文化 12
1．4．1 害怕變化 12
1．4．2 知識倉庫 13
1．5 小結 14
第2章 找到起點 15
2．1 剋服恐懼和沮喪 15
2．1．1 恐懼 16
2．1．2 沮喪 18
2．2 收集軟件的有用數據 19
2．2．1 bug和編碼標準違例 20
2．2．2 性能 20
2．2．3 錯誤計數 23
2．2．4 對常見的任務計時 23
2．2．5 常用文件 24
2．2．6 度量可度量的一切 25
2．3 用FindBugs、PMD和Checkstyle審查代碼庫 25
2．3．1 在IDE中運行FindBugs 26
2．3．2 處理誤報 29
2．3．3 PMD和Checkstyle 32
2．4 用Jenkins進行持續審查 34
2．4．1 持續集成和持續審查 34
2．4．2 安裝和設置Jenkins 35
2．4．3 用Jenkins構建和審查代碼 36
2．4．4 還能用Jenkins做些什麼 37
2．4．5 SonarQube 39
2．5 小結 39
第二部分　通過重構改善代碼庫
第3章 準備重構 43
3．1 達成團隊共識 44
3．1．1 傳統主義者 44
3．1．2 反傳統主義者 46
3．1．3 一切都在於溝通 47
3．2 獲得組織的批準 48
3．2．1 使它變得正式 48
3．2．2 備用計劃：神秘的20%計劃 49
3．3 選擇重構目標 50
3．4 決策時間：重構還是重寫 51
3．4．1 不應該重寫的情況 52
3．4．2 從頭重寫的好處 55
3．4．3 重寫的必要條件 56
3．4．4 第三種方式：增量重寫 57
3．5 小結 58
第4章 重構 59
4．1 有紀律的重構 59
4．1．1 避免麥剋白的悲劇 59
4．1．2 把重構和其他的工作分開 60
4．1．3 依靠IDE 61
4．1．4 依靠版本控製係統 64
4．1．5 Mikado方法 65
4．2 常見的遺留代碼的特徵和重構 66
4．2．1 陳舊代碼 66
4．2．2 有毒的測試 68
4．2．3 過多的null 70
4．2．4 不必要的可變狀態 73
4．2．5 錯綜復雜的業務邏輯 74
4．2．6 視圖層中的復雜性 79
4．3 測試遺留代碼 83
4．3．1 測試不可測試的代碼 83
4．3．2 沒有單元測試的迴歸測試 86
4．3．3 讓用戶為你工作 88
4．4 小結 89
第5章 重搭架構 90
5．1 什麼是重搭架構 90
5．2 將單體應用程序分解為模塊 92
5．2．1 案例研究—日誌管理應用程序 92
5．2．2 定義模塊和接口 94
5．2．3 構建腳本和依賴管理 95
5．2．4 分拆模塊 96
5．2．5 引入Guice 97
5．2．6 Gradle來瞭 98
5．2．7 結論 98
5．3 將Web應用程序分發到服務 99
5．3．1 再看一下Orinoco．com 99
5．3．2 選擇一個架構 100
5．3．3 繼續采用單體架構 101
5．3．4 前後端分離 103
5．3．5 麵嚮服務架構 106
5．3．6 微服務 108
5．3．7 Orinoco．com應該做什麼 109
5．4 小結 109
第6章 大規模重寫 111
6．1 決定項目範圍 112
6．1．1 項目目標是什麼 112
6．1．2 記錄項目範圍 113
6．2 從過去學習 114
6．3 如何處理數據庫 115
6．3．1 共享現有數據庫 116
6．3．2 創建一個新數據庫 119
6．3．3 應用程序間通信 124
6．4 小結 125
第三部分　重構之外——改善項目工作流程與基礎設施
第7章 開發環境的自動化 129
7．1 工作的第一天 129
7．1．1 搭建用戶活動儀錶盤開發環境 130
7．1．2 齣瞭什麼問題 132
7．2 一個好的README文件的價值 134
7．3 用Vagrant和Ansible對開發環境進行自動化 135
7．3．1 Vagrant介紹 135
7．3．2 為用戶活動儀錶盤項目搭建Vagrant 136
7．3．3 用Ansible進行自動配置 137
7．3．4 添加更多的角色 139
7．3．5 移除對外部數據庫的依賴 141
7．3．6 工作的第一天—再來一次 142
7．4 小結 143
第8章 將自動化擴展到測試環境、預生産環境以及生産環境 144
8．1 自動化基礎設施的好處 145
8．1．1 保證環境一緻性 145
8．1．2 易於更新軟件 145
8．1．3 易於搭建新環境 145
8．1．4 支持追蹤配置更改 146
8．2 將自動化擴展到其他環境 146
8．2．1 重構Ansible腳本以處理多種環境 146
8．2．2 為Ansible角色和playbook搭建庫 150
8．2．3 讓Jenkins負責 152
8．2．4 常見問題 154
8．3 移到雲上 155
8．3．1 不可變基礎設施 156
8．3．2 DevOps 156
8．4 小結 157
第9章 對遺留軟件的開發、構建以及部署過程進行現代化 158
9．1 開發、構建以及部署遺留軟件的睏難 158　　
9．1．1 缺乏自動化 158
9．1．2 過時的工具 160
9．2 更新工具鏈 160
9．3 用Jenkins實現持續集成與自動化 163
9．4 自動發布和部署 165
9．5 小結 172
第10章 停止編寫遺留代碼 173
10．1 源代碼並不是項目的全部 173
10．2 信息不能是自由的 174
10．2．1 文檔 174
10．2．2 促進溝通 175
10．3 工作是做不完的 176
10．3．1 定期進行代碼評審 176
10．3．2 修復一扇窗戶 176
10．4 自動化一切 177
10．5 小型為佳 178
10．6 小結 180

《代碼的生命綫：應對復雜遺留係統的重塑之道》 引言 在軟件開發的漫長旅途中，我們常常會遇到一個無可迴避的挑戰——遺留係統。它們是企業運營的基石，承載著多年的業務邏輯和用戶信任，但也可能成為阻礙創新的“代碼泥沼”。這些係統往往因技術陳舊、文檔缺失、耦閤緊密而難以理解、維護和擴展，如同古老的巨石，既是價值的象徵，也是前進的障礙。本書《代碼的生命綫：應對復雜遺留係統的重塑之道》並非一本介紹具體操作步驟的書籍，而是旨在為開發者、技術領導者和架構師提供一套關於遺留係統重塑的哲學思考、策略藍圖和實踐智慧。我們將深入探討遺留係統為何會産生，它們所帶來的挑戰，以及如何在不冒不必要的風險的前提下，逐步、穩健地將其轉型為適應未來發展需求的高效、可維護的現代化係統。 第一章：遺留係統的“前世今生”——理解其根源與價值 在著手任何“重建”之前，首先必須深刻理解遺留係統的本質。它們並非憑空齣現，而是曆史的産物。本書將追溯軟件發展各個階段的典型技術棧、開發模式和業務驅動因素，解析為何某些係統會逐漸演變成如今的狀態。我們將探討早期係統設計理念的局限性，例如過度的“硬編碼”、缺乏模塊化思維、以及對未來技術演進預見不足等。同時，我們也會強調遺留係統並非一無是處，它們往往凝聚瞭企業最核心的業務流程和寶貴的知識財富。理解這些係統的價值，是後續一切重塑工作的齣發點和價值衡量基準。我們將通過案例分析，展示遺留係統在業務連續性、數據積纍和用戶習慣方麵的重要性，幫助讀者認識到“保護”和“傳承”遺留係統中的精華，是重塑成功的關鍵。 第二章：揭開“遺留”的麵紗——挑戰與機遇並存的現實 “遺留”二字常常伴隨著“風險”、“成本”和“低效”。本章將深入剖析遺留係統帶來的典型挑戰。我們將詳細討論代碼的可讀性差、測試覆蓋率低、技術債務堆積、缺乏現代化開發工具支持、以及潛在的安全隱患等問題。然而，挑戰的背後往往也隱藏著巨大的機遇。每一次對遺留係統的改造，都是一次技術升級、流程優化的契機。本書將引導讀者從戰略層麵思考，如何將這些挑戰轉化為驅動創新的動力，例如通過引入自動化測試來提升代碼質量，通過微服務化改造來提高係統的靈活性，通過雲原生技術來增強係統的彈性與可擴展性。我們將強調，對遺留係統的恐懼源於對未知的擔憂，而清晰的認識和周密的計劃，是剋服恐懼、抓住機遇的關鍵。 第三章：重塑的策略藝術——在保守與激進間的平衡之道 麵對一個龐大而復雜的遺留係統，簡單粗暴的“推倒重來”往往是不可取且高風險的。本書將重點闡述一係列“漸進式重塑”的策略。我們將詳細探討“絞殺者模式”（Strangler Fig Pattern）的應用，如何逐步將新功能和新服務接入現有係統，最終將遺留係統“蠶食”殆盡。我們還將介紹“數據遷移策略”、“API封裝”、“服務拆分”等核心概念，以及在不同場景下選擇最適閤的策略組閤。本書會特彆強調“最小可行産品”（MVP）的思維在遺留係統改造中的重要性，以及如何通過迭代的方式，逐步驗證改造效果，降低整體風險。此外，我們還將討論如何評估不同重塑策略的成本效益，以及如何根據業務優先級來製定改造路綫圖。 第四章：技術工具箱的升級——為遺留係統注入新活力 盡管遺留係統可能使用著老舊的技術，但重塑過程離不開現代化的技術工具。本章將重點介紹一係列能夠幫助我們理解、分析、重構和部署遺留係統的技術手段。我們將討論靜態代碼分析工具的應用，如何揭示代碼中的潛在問題和“壞味道”。自動化測試框架的重要性將貫穿始終，從單元測試到集成測試，再到端到端測試，我們將探討如何逐步建立一套完善的自動化測試體係，為重構提供安全網。此外，本書還會介紹API網關、服務注冊與發現、容器化技術（如Docker）、持續集成/持續部署（CI/CD）流水綫等現代化架構實踐，以及它們如何幫助我們更好地管理和演進遺留係統。我們將強調，選擇閤適的技術棧並非盲目追隨潮流，而是要根據遺留係統的特點和重塑目標來做齣明智的決策。 第五章：架構的演進之路——從整體到局部的現代化蛻變 架構是遺留係統重塑的靈魂。本書將深入探討如何對遺留係統的架構進行演進。我們將從宏觀層麵齣發，討論如何識彆係統中的“技術孤島”和“單體巨獸”，並逐步將其解耦，引入微服務、事件驅動架構等現代化設計模式。我們將詳細講解“領域驅動設計”（DDD）在理解和拆分復雜業務域中的作用，以及如何通過“限界上下文”（Bounded Context）來劃分服務邊界。本書還將深入剖析API設計的重要性，如何通過統一的API層來屏蔽底層技術的差異，為前端和第三方集成提供穩定可靠的接口。此外，我們還會探討數據架構的演進，如何從集中式數據庫走嚮分布式的、更具彈性的數據存儲方案。 第六章：人的因素與文化變革——擁抱變化，共創未來 技術改造的成功，最終取決於人的努力和團隊的協作。本書將把目光聚焦於“人”這個關鍵因素。我們將探討如何建立一支能夠應對遺留係統挑戰的跨職能團隊，以及如何培養團隊成員的“遺留係統思維”。本書會強調溝通、協作和知識共享在重塑過程中的重要性。我們將討論如何管理利益相關者的期望，以及如何通過有效的溝通，爭取資源和支持。此外，本書還將探討文化變革的力量，如何鼓勵團隊擁抱新技術、新方法，並從中學習成長。我們將強調，成功的遺留係統重塑，不僅僅是技術的升級，更是組織文化的積極蛻變。 第七章：風險管理與質量保障——在不確定中穩健前行 遺留係統的重塑充滿瞭不確定性，因此，有效的風險管理和質量保障是必不可少的。本書將深入探討如何識彆、評估和規避重塑過程中可能齣現的各種風險，從技術風險到業務風險，再到項目管理風險。我們將詳細介紹“迴歸測試”、“性能測試”、“安全測試”等關鍵的質量保障環節，以及如何利用自動化工具來提高測試效率和覆蓋率。本書還將討論“迴滾策略”和“故障轉移機製”的重要性，確保在齣現問題時能夠迅速恢復。我們將強調，質量不是在項目結束時纔檢查，而是貫穿於整個重塑過程的始終。 第八章：案例精粹與經驗總結——他山之石，可以攻玉 理論固然重要，但成功的實踐經驗更是無價之寶。本章將通過精選的案例研究，展示不同行業、不同規模的組織在遺留係統重塑過程中所遇到的問題、采取的策略以及取得的成就。這些案例將涵蓋從銀行核心係統改造，到電商平颱架構升級，再到傳統製造業數字化轉型等多個維度。我們將深入分析每個案例的成敗之處，提煉齣可供藉鑒的經驗和教訓。本書將鼓勵讀者跳齣自己的特定場景，從更廣闊的視角審視遺留係統重塑的普遍規律。 結論：擁抱變革，再塑輝煌 《代碼的生命綫：應對復雜遺留係統的重塑之道》並非提供一蹴而就的解決方案，而是希望成為指引您穿越遺留係統“迷霧”的燈塔。我們相信，每一個遺留係統都蘊藏著巨大的潛能，隻要我們以審慎的態度、創新的思維和堅定的執行力去麵對，就能夠為其注入新的生命力，使其重新煥發光彩，驅動企業走嚮更輝煌的未來。本書的目標是賦能您，讓您能夠更有信心地規劃、執行和管理遺留係統的重塑項目，最終實現技術與業務的和諧統一，為組織的長期發展奠定堅實的基礎。

評分☆☆☆☆☆

我一直在尋找能夠幫助我理解和應對復雜技術挑戰的資源，尤其是那些關於如何處理“老舊”但又至關重要的軟件係統的。這本書的齣現，讓我眼前一亮。我特彆看重的是書中是否能夠提供一些前瞻性的視角，不僅僅是解決當前的問題，更是為未來的係統演進打下基礎。 我希望這本書能深入探討在遺留係統重建過程中，如何引入新的技術和架構模式，同時又不至於“推倒重來”，導緻巨大的風險。例如，書中是否會講解如何逐步引入微服務架構，或者如何利用容器化技術來隔離和管理遺留係統的不同模塊？更重要的是，我期待書中能提供一些關於如何在不犧牲性能和可維護性的前提下，提升遺留係統安全性的具體實踐。關於如何評估不同重構方案的成本與收益，以及如何在長期的維護過程中，持續地保持係統的健康度，也是我非常關注的方麵。

評分☆☆☆☆☆

我是一名長期與遺留係統打交道的開發者，深知其帶來的無奈與挑戰。每次麵對那些如同一團亂麻的代碼，我都希望有一本能夠指引方嚮的書。這本書的題目《遺留係統重建實戰》立刻吸引瞭我。我關注的重點在於“實戰”二字。我希望這本書能夠提供具體的案例分析，詳細闡述如何一步步地拆解、重構、甚至重寫遺留係統。 特彆想瞭解的是，書中對於“零停機”重構是否有深入的探討。在實際工作中，很多遺留係統都承載著關鍵業務，停機時間意味著巨大的損失。因此，如何設計和實施能夠平滑過渡的重構方案，是我最關心的問題。比如，是否會介紹一些“絞殺者”模式（Strangler Fig Pattern）的具體應用場景和實踐經驗？又或者，書中是否會提供一些關於如何安全地遷移數據，以及如何在並行運行新舊係統時處理數據一緻性的詳細指導？另外，我也期待書中能分享一些關於如何識彆係統中的“關鍵路徑”，以及如何優先處理那些影響最大、風險最高的模塊的策略。

評分☆☆☆☆☆

在信息爆炸的時代，尋找一本真正能解決實際問題的技術書籍，如同在大海撈針。我一直對係統架構和重構領域充滿興趣，特彆是那些能夠提供切實可行的解決方案，而非空談理論的書籍。最近，我偶然發現一本名為《遺留係統重建實戰》的書，雖然我還沒來得及深入閱讀，但從它紮實的標題和市麵上稀缺的同類主題來看，我對其抱有極大的期待。 我特彆關注的是書中是否能深入剖析遺留係統存在的普遍痛點，例如技術債務的纍積、代碼的脆弱性、文檔的缺失，以及團隊在麵對這些挑戰時可能遇到的阻力。一個好的“實戰”書籍，應該能夠觸及這些核心問題，並提齣行之有效的診斷方法。我希望這本書不僅僅是列舉一些重構技巧，而是能教會讀者如何係統地評估一個遺留係統的健康狀況，理解其演進的脈絡，並在此基礎上製定齣閤理的重建策略。例如，書中是否會提供一些量化的指標來衡量遺留係統的“老舊”程度，或者介紹一些工具來幫助我們自動化地識彆代碼中的壞味道？此外，對於那些龐大且復雜到令人望而生畏的係統，如何在不影響核心業務的情況下，分階段、有計劃地進行改造，也將是我非常期待的內容。

評分☆☆☆☆☆

在我看來，許多關於軟件開發的圖書，雖然理論紮實，但在實際操作層麵往往顯得過於抽象，難以直接套用到我們這些在“一綫”奮戰的開發者身上。《遺留係統重建實戰》這個書名，精準地擊中瞭我的痛點。我對於書中所述的“重建”過程，有著非常具體和現實的期盼。 我尤其感興趣的是，書中是否會涉及如何構建一個能夠有效支持遺留係統重建的團隊文化和工作流程。一個成功的重建項目，不僅僅是技術層麵的突破，更是組織層麵協同努力的結果。例如，書中是否會討論如何與業務方溝通，爭取他們對重建項目的理解和支持？又或者，它會提供一些關於如何培訓團隊成員，讓他們掌握必要的遺留係統分析和重構技能的建議？此外，我還好奇書中是否會提及一些在重建過程中可能遇到的非技術性挑戰，比如如何處理遺留係統的“隱性知識”傳承，以及如何在緊迫的時間錶下平衡質量和速度。

評分☆☆☆☆☆

從事軟件開發多年，我深切體會到遺留係統帶來的“甜蜜的負擔”。它們是企業核心業務的基石，卻也常常成為技術創新的桎梏。《遺留係統重建實戰》這個名字，就像沙漠中的甘泉，瞬間點燃瞭我探索的渴望。 我最期待的是書中能夠提供一係列可復製、可藉鑒的“實戰”案例，而不僅僅是停留在理論層麵。我希望能夠看到詳細的技術棧對比、架構演進圖示、以及在麵對具體技術難題時，作者是如何一步步分析、決策並最終實施解決方案的。例如，書中是否會展示如何利用“測試驅動開發”（TDD）等敏捷方法來重構遺留代碼，或者如何通過自動化測試來確保重構過程的安全性？我也非常好奇書中是否會分享一些關於如何選擇閤適的工具鏈，以及如何構建持續集成/持續部署（CI/CD）流水綫來支持遺留係統的現代化改造。最後，如何衡量一個遺留係統重建項目的成功與否，以及如何建立一個長期的維護和演進機製，也是我希望書中能有所解答的。

評分☆☆☆☆☆

還不錯看完瞭，漲知識

評分☆☆☆☆☆

還不錯，蠻好用的，京東你懂得

評分☆☆☆☆☆

好好學習，天天嚮上。哈，加油。

評分☆☆☆☆☆

公司買的書，送的快，質量也不錯

評分☆☆☆☆☆

好 很好 非常好

評分☆☆☆☆☆

很不錯 價格實惠 這種書基本也就看一遍

評分☆☆☆☆☆

很好

評分☆☆☆☆☆

這本書估計在倉庫放瞭不少時間瞭吧，封皮有點差

評分☆☆☆☆☆

還沒看，書是正版的。