掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
遺留系統重建實戰 版權信息
- ISBN：9787115465856
- 條形碼：9787115465856 ; 978-7-115-46585-6
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>>
遺留系統重建實戰 本書特色
正如本書作者所言，大多數開發人員的主要時間都是花費在與現有的軟件打交道上，而不是編寫全新的應用程序。相信開發人員或多或少都遇到過與遺留系統相關的問題或者困惑，本書致力于幫開發人員回答這些問題，更重要的是，幫開發人員避免把自己當前開發的系統變成別人將來要面臨的遺留問題。 本書篇幅不長，但涵蓋的內容很廣，例證豐富，有大量的示例代碼（主要使用Java或C#編寫），深入淺出地介紹了工作在遺留系統中會遇到的各種問題及應對方法。書中不僅包含技術性的內容—如何選擇構建項目的工具，如何自動化構建基礎設施，如何決定并進行重構或重寫等，也包含非技術性的內容—應該建設什么樣的團隊文化，如何引入代碼評審等活動，如何進行團隊知識的傳播、改進溝通方式等。
遺留系統重建實戰 內容簡介
作為開發人員，你可能會從另一個團隊接手一個項目，而且該項目是基于現有代碼庫的，擁有很多設計模式、使用假設、基礎設施和工具。幸運的是，有一些方法可以為遺留項目注入新的活力，這樣你就可以維護、改進和擴展它們，而不必顧及它們的局限性。 這是一本以經驗為主導的指南，能使遺留軟件項目脫胎換骨。它涵蓋了重構、質量度量學、工具鏈和工作流、持續集成、基礎設施自動化以及組織文化等內容。在技術層面，讀者將學習如何給代碼模塊化引進依賴注入，如何定量地衡量軟件質量，以及如何實現基礎設施的自動化。在策略層面，讀者將能學到的實踐有：軟件是應該重寫還是應該重構，團隊的組織架構應該是什么樣的，以及如何讓管理層意識到軟件質量的重要性。本書的核心議題包括解析和模塊化棘手的代碼結構、集成和自動化測試、替換過時的構建系統，以及用Vagrant和Ansible 之類的工具實現基礎設施自動化。 本書主要內容 ● 重構遺留代碼庫。 ● 持續審查和持續集成。 ● 遺留基礎設施的自動化。 ● 給老代碼加新測試。 ● 單體應用的模塊化。 本書面向的讀者對象是熟悉面向對象語言（如Java 或C#）的開發人員和團隊領導。
遺留系統重建實戰 目錄
目錄
**部分 開始
第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
**部分 開始
第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
展開全部
遺留系統重建實戰 作者簡介
作者簡介 Chris Birchall 是倫敦《衛報》的高-級開發工程師，致力于為網站提供支持的后臺服務。此前，他做過很多不同的項目，包括日本zui大的醫療門戶網站、高性能日志管理軟件、自然語言分析工具和許多移動網站。他擁有劍橋大學計算機科學專業的學士學位。 譯者簡介 張喻，ThoughtWorks咨詢師，熱愛技術，熱衷編程。目前主要從事后端API的開發、部署、維護等相關工作，在整潔代碼、敏捷實踐和軟件開發高效團隊方面有豐富的理論和實踐經驗。 張耀丹，ThoughtWorks咨詢師，曾長期參與大型遺留系統的開發與改進，在Java服務器端技術、大型系統架構演進、微服務轉型、DevOps和云計算方面有豐富的經驗。 禚嫻靜，ThoughtWorks咨詢師，樂于知識分享與傳播。擁有多年企業和互聯網應用的開發實戰經驗，專注于敏捷實踐、軟件架構和持續交付領域，在.NET技術棧和微服務架構演化等方面有豐富的積累。
書友推薦
- >
苦雨齋序跋文-周作人自編集
- >
推拿
- >
姑媽的寶刀
- >
隨園食單
- >
詩經-先民的歌唱
- >
大紅狗在馬戲團-大紅狗克里弗-助人
- >
自卑與超越
- >
史學評論
本類暢銷
