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

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

第二部分 重構基本概念
第二單元 何為重構

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

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

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

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

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

第三單元 重構

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

內(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

第四單元 重構難題

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

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

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

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

內(nèi)容二：高質(zhì)量函數(shù)/過程
1.為什么需要函數(shù)
2.函數(shù)復雜度度量
3.函數(shù)圈復雜度以及度量
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ù)重構之道—抽取方法(Extract Method)和抽取對象函數(shù)
10.函數(shù)命名—怎樣取好的函數(shù)名
11.通過大量項目代碼分析,函數(shù)的遇到的各種問題,如何編程高質(zhì)量函數(shù)

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

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

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

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

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

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

第七單元 模塊重構

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

第八單元 架構重構

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


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

第九單元 重構管理

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