遺留系統重建實戰 (Re-Engineering Legacy Software) 遗留系统重建实战
[英]克裡斯·伯查爾
- 出版商: 人民郵電
- 出版日期: 2017-09-01
- 售價: $330
- 貴賓價: 9.5 折 $314
- 語言: 簡體中文
- 頁數: 180
- 裝訂: 平裝
- ISBN: 7115465851
- ISBN-13: 9787115465856
-
相關分類:
Refactoring
- 此書翻譯自: Re-Engineering Legacy Software (Paperback)
立即出貨 (庫存 < 4)
買這商品的人也買了...
-
$480$408 -
$281程序員修煉之道 :從小工到專家 (The Pragmatic Programmer: From Journeyman to Master)
-
$301軟件設計重構
-
$270$257 -
$480$360 -
$650$507 -
$780$616 -
$450$356 -
$500$390 -
$281修改軟件的藝術 : 構建易維護代碼的 9條最佳實踐 (Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software)
-
$594$564 -
$306現代 API : 通往架構師之門
-
$680$530 -
$580$435 -
$520$411 -
$800$600 -
$720$562 -
$1,000$780 -
$704$662 -
$520$406 -
$594$564 -
$630$599 -
$734掌握分佈式跟蹤:微服務和復雜系統性能分析
-
$520$390 -
$580$458
相關主題
商品描述
正如本書作者所言,大多數開發人員的主要時間都是花費在與現有的軟件打交道上,而不是編寫全新的應用程序。相信開發人員或多或少都遇到過與遺留系統相關的問題或者困惑,本書致力於幫開發人員回答這些問題,更重要的是,幫開發人員避免把自己當前開發的系統變成別人將來要面臨的遺留問題。
本書篇幅不長,但涵蓋的內容很廣,例證豐富,有大量的示例代碼(主要使用Java或C#編寫),深入淺出地介紹了工作在遺留系統中會遇到的各種問題及應對方法。書中不僅包含技術性的內容—如何選擇構建項目的工具,如何自動化構建基礎設施,如何決定並進行重構或重寫等,也包含非技術性的內容—應該建設什麽樣的團隊文化,如何引入代碼評審等活動,如何進行團隊知識的傳播、改進溝通方式等。
作者簡介
Chris Birchall
倫敦《衛報》的高級開發工程師,致力於為網站提供支持的後台服務。此前,他做過很多不同的項目,包括日本zui大的醫療門戶網站、高性能日誌管理軟件、自然語言分析工具和許多移動網站。他擁有劍橋大學計算機科學專業的學士學位。
目錄大綱
第一部分開始
第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