第一部分 為什么軟件需要及時重構(gòu)
第一單元 軟件代碼腐爛

內(nèi)容一：軟件業(yè)者的反思： 軟件腐爛
1.軟件腐爛（Software rot），也叫做代碼腐爛（code rot）或軟件腐朽（software decay）。它描述了隨著時間的逝去感知到軟件的緩慢衰退，其將最終導(dǎo)致它變得不完善、不可使用或難以維護。
2.軟件腐爛（Software rot）有兩種形式：
3.1)隱匿的腐爛：軟件逐漸不再（仍）被使用隨著剩余的應(yīng)用程序的改變變得不能用。它已經(jīng)被觀察到不再被使用的軟件有可能一年的半衰期；
4.2) 活動的腐爛：軟件隨著不斷地被修改趨向于失去它的完整性。
5.破窗效應(yīng)與技術(shù)債務(wù)
6.案例演示1-通過演示大型項目，隨著客戶需求的變化，導(dǎo)致軟件結(jié)構(gòu)混亂，大家反思，為什么？ 你認為軟件腐爛的原因？ 反思你們公司的軟件系統(tǒng)也面臨這樣的問題嗎？

第二部分 重構(gòu)基本概念
第二單元 何為重構(gòu)

內(nèi)容一：重構(gòu)
1.重構(gòu)概述
2.何時重構(gòu)
3.重構(gòu)的誤區(qū)
4.重構(gòu)是持續(xù)進行的,不要先編寫爛代碼，再抽出重構(gòu)
5.如何發(fā)現(xiàn)哪些地方需要重構(gòu)
6.如何保證重構(gòu)的正確
7.如何測試重構(gòu)
8.通過一個小案例演示重構(gòu)的基本思想(什么時間重構(gòu),如何發(fā)現(xiàn)重構(gòu)點,如何保證重構(gòu)的正確性,最后如何驗收)

內(nèi)容二：案例—通過實際項目演示重構(gòu)
1.介紹項目需求情況,進行設(shè)計
2.閱讀代碼指出代碼壞癥狀
3.通過重構(gòu)逐步改善代碼質(zhì)量
4.通過該案例演示重構(gòu)的過程，我們遇到的難處，如何解決？

內(nèi)容三：重構(gòu)關(guān)鍵—代碼的壞味道?
1.代碼壞味道概述
2.代碼壞味道的分類
3.識別代碼壞味道，是重構(gòu)的最重要一步
4.所謂重構(gòu)，無非就是嗅到壞味道，然后，一小步一小步的改了它。問題是，很多人對壞味道的容忍度讓他們嗅不到壞味道，
5.案例分析—通過真實項目的代碼，分析代碼壞味道

內(nèi)容四：代碼壞味道—代碼的質(zhì)量底線
1.代碼壞味道概述
2.代碼壞味道的分類
3.代碼壞味道----低級篇(重復(fù)的代碼、過長的函數(shù)、過大的類、過長的參數(shù)列表、發(fā)散式變化、分散的修改)
4.代碼壞味道----中級篇(偽面向?qū)ο蟮恼{(diào)用、數(shù)據(jù)泥團、基本類型的誤用、switch-case結(jié)構(gòu)的誤用、平行繼承體系、過薄的類、只有局部意義的成員變量)
5.代碼壞味道----高級篇
6.通過案例,讓學(xué)員尋找代碼壞味道
7.可以根據(jù)客戶現(xiàn)在的項目作為案例進行現(xiàn)場分析,找出相應(yīng)的代碼壞味道

內(nèi)容五：某項目分析----重點了解現(xiàn)實項目代碼的充斥大量壞味道
1.介紹項目需求情況,閱讀現(xiàn)有代碼指出代碼壞癥狀
2.不看不知道,代碼到底有多爛—觸目驚心的代碼
3.通過重構(gòu)逐步改善代碼質(zhì)量
4.本案例學(xué)習(xí)多種重構(gòu)方式

第三單元 重構(gòu)

內(nèi)容一：重構(gòu)
1.重構(gòu)手法概述
2.簡要演示重構(gòu)的主要手法
3.使用IDE重構(gòu)工具進行重構(gòu)
4.通過案例演示如何通過重構(gòu)工具完成重構(gòu)

內(nèi)容二：Rhythm of Refactoring -baby step
1.Baby steps involve making a few code changes and then checking your work by running tests. Typical refactorings take seconds or minutes to perform
2.The Rhythm of Refactoring goes like this:
a)Verify that all automated tests (microtests) pass?
b)Decide what code to change?
c)Implement one or more refactorings carefully?
d)Run the microtests whenever you wish to confirm that changes have not altered system behavior?
e)Repeat until the refactoring is complete or revert to an earlier state?

內(nèi)容三： Refactoring Strategies & Tactics?
1.Refactoring Strategy: Piecemeal Refactoring?
2.Refactoring Strategy:Divide & Conquer?
3.Refactoring Strategy:Narrowed Change?
4.Refactoring Strategy:Parallel Change?
5.Refactoring Strategy:Unified Methods?
6.Refactoring Strategy:Evolved Target?
7.Refactoring Strategy: Graceful Retreat?
8.Refactoring Strategy: Gradual Cutover?
9.Refactoring Strategy: Preparing for Change?
10.Refactoring Tactic: Rejected Parameter?
11.Refactoring Tactic: Caller Swap?
12.Refactoring Tactic:Encapsulated Dependency

第四單元 重構(gòu)難題

內(nèi)容一：重構(gòu)技術(shù)難題
1.如何發(fā)現(xiàn)重構(gòu)點
2.知道重構(gòu)的目標（結(jié)果）
3.如何去重構(gòu)—重構(gòu)實踐
4.如何保證重構(gòu)的正確性-單元測試

內(nèi)容二：重構(gòu)業(yè)務(wù)難題
1.重構(gòu)手法概述
2.簡要演示重構(gòu)的主要手法

第三部分 重構(gòu)實戰(zhàn)一函數(shù)相關(guān)重構(gòu)
第五單元 函數(shù)相關(guān)重構(gòu)

內(nèi)容一：函數(shù)的重構(gòu)
1.函數(shù)的重構(gòu)
2.巨型函數(shù)的種類
a)項目列表式巨型方法
b)鋸齒狀巨型方法
3.分解函數(shù)
4.助手方法提取
5.利用自動重構(gòu)對付巨型方法
6.利用手工重構(gòu)對付巨型方法
7.引入感知變量
8.函數(shù)依賴收集
9.分解助手方法和方法對象
10.通過案例介紹長函數(shù)的重構(gòu)最佳實踐

內(nèi)容二：高質(zhì)量函數(shù)/過程
1.為什么需要函數(shù)
2.函數(shù)復(fù)雜度度量
3.函數(shù)圈復(fù)雜度以及度量
4.函數(shù)抽象層次-單一抽象層次原則SLAP(Single Level of Abstrction Principle)
5.函數(shù)實現(xiàn)模式之—組合函數(shù)(Composed Method)
6.萬惡之源—函數(shù)過長
7.函數(shù)的單一職責
8.函數(shù)第一原則:是要短小,函數(shù)第二原則:是還要短小,函數(shù)第三原則:是必須短小
9.函數(shù)重構(gòu)之道—抽取方法(Extract Method)和抽取對象函數(shù)
10.函數(shù)命名—怎樣取好的函數(shù)名
11.通過大量項目代碼分析,函數(shù)的遇到的各種問題,如何編程高質(zhì)量函數(shù)

內(nèi)容三：函數(shù)易理解與溝通
1.函數(shù)主體流
2.函數(shù)的異常處理
3.函數(shù)主題流程簡化方法1-助手方法
4.助手方法的應(yīng)用場景
5.助手方法的效果
6.函數(shù)主題流程簡化方法2-函數(shù)對象（MethodObject）
通過真實項目代碼進行分析，如果提高代碼的可讀性

內(nèi)容四：函數(shù)10個一
1.每個變量只用于單一用途
2.每一個行代碼只表達一件事
3.一個循環(huán)只做一件事
4.單一抽象層次原則
5.代碼組織得一次只做一件事情
6.函數(shù)體內(nèi)只關(guān)注一種變化的原因（動機）
7.函數(shù)應(yīng)該遵守單一職責
8.函數(shù)圈復(fù)雜應(yīng)該小于一十
9.函數(shù)第一原則是必須要短小
10.編寫函數(shù)時必須一心一意，專注，懷有謙卑的心態(tài)

第四部分 重構(gòu)實戰(zhàn)4一模塊/架構(gòu)重構(gòu)
第六單元 重構(gòu)模式

內(nèi)容一：重構(gòu)到模式
1.軟件設(shè)計的基本原則
2.設(shè)計模式概述
3.設(shè)計模式的本質(zhì)論
4.設(shè)計模式如何適應(yīng)變化和封裝
5.重構(gòu)到模式的思路

內(nèi)容二：案例---重點介紹重構(gòu)基本類型依賴和對應(yīng)模式
1.通過案例學(xué)習(xí)以下重構(gòu)到模式手段
2.以State取代狀態(tài)改變條件語句
3.以Strategy取代條件邏輯
4.以Composite取代隱含樹
5.以Interpreter取代隱式語言
6.轉(zhuǎn)移裝飾功能到Decorator
7.用Builder封裝Composite
8.重點學(xué)習(xí)案例的重構(gòu)到模式的過程

內(nèi)容三：案例---重點介紹重構(gòu)代碼重復(fù)和對應(yīng)模式
1.通過案例學(xué)習(xí)以下重構(gòu)到模式手段
2.構(gòu)造Template Method
3.以Composite取代一/多之分
4.引入Null Object
5.用Adapter統(tǒng)一接口
6.用Fatory Method引入多態(tài)創(chuàng)建
7.重點學(xué)習(xí)案例的重構(gòu)到模式的過程

第七單元 模塊重構(gòu)

內(nèi)容一：模塊重構(gòu)?
1.結(jié)合以下問題進行分析，具體內(nèi)容還在整理之中
2.由于有些同事不會去分析數(shù)據(jù)流，不會去根據(jù)數(shù)據(jù)流去抽象和設(shè)計，從而導(dǎo)致了數(shù)據(jù)流的不少處理環(huán)節(jié)的代碼互相耦合嚴重，公有變量不合理。建議去談?wù)剰臄?shù)據(jù)流進行抽象和設(shè)計的方法。
3.我們提供給客戶的軟件產(chǎn)品，二次開發(fā)不太方便（可讀性差，可擴展性差，可維護性差）。如何通過重構(gòu)去達成更好的二次開發(fā)便利性？
4.如何通過合理的調(diào)整，確保迭代開發(fā)的過程真正做到“增量開發(fā)”，而不是“修改”已有代碼？
5. 如何屏蔽硬件變化導(dǎo)致的軟件系統(tǒng)需要大幅度的修改？
6.分析某項目,演示模塊重構(gòu),如何在大型應(yīng)用系統(tǒng)進行模塊重構(gòu)

第八單元 架構(gòu)重構(gòu)

內(nèi)容一: 架構(gòu)重構(gòu)
1.軟件架構(gòu)概述
2.遺留系統(tǒng)的軟件架構(gòu)恢復(fù)
3.軟件架構(gòu)的重構(gòu)時機
4.軟件架構(gòu)的重構(gòu)步驟
5.架構(gòu)壞味道
6.架構(gòu)重構(gòu)策略


內(nèi)容二：案例分析—某互聯(lián)網(wǎng)項目架構(gòu)重構(gòu)(根據(jù)時間調(diào)整)
1.項目背景以及相關(guān)需求
2.軟件架構(gòu)的演進與重構(gòu)過程
3.質(zhì)量屬性對軟件架構(gòu)的驅(qū)動
4.架構(gòu)的可擴展性架構(gòu)
5.緩存技術(shù)在架構(gòu)之中的應(yīng)用
6.Web層的架構(gòu)策略
7.中間層的架構(gòu)和集群策略
8.大型并發(fā)系統(tǒng)Session的復(fù)制和容錯架構(gòu)策略
9.數(shù)據(jù)的架構(gòu)
10.該案例主要演示軟件架構(gòu)的重構(gòu)策略

第九單元 重構(gòu)管理

內(nèi)容一：安全重構(gòu)?
1.重構(gòu)的恐懼心里
2.重構(gòu)勇氣
3.安全重構(gòu)和祈禱式重構(gòu)
4.安全重構(gòu)保證
5.通過案例如何保證重構(gòu)的正確性