重构-复杂遗留系统重构与维护

架构设计 / 2020-04-26 15:22:55
重构-复杂遗留系统重构与维护
    马上咨询

    刘捷  曾任BEA中國(guó)专业服務(wù)部 高级架构师顾问　 

    现任职Oracle架构咨询顾问，帮企业诊断架构性能(néng)问题，曾任职BEA(中國(guó))资深软件架构师，十余年的企业软件架构、开发和管理(lǐ)经验，侧重于企业应用(yòng)软件架构设计.主要负责客户大型项目的架构设计和研发，作為(wèi)技术专家保证项目的成功实施，运行和维护。参加过全國(guó)/全省多(duō)个大型的计算机应用(yòng)项目，擅長(cháng)的领域包括電(diàn)信，金融、税務(wù),大型互联网web2.0应用(yòng)等。此前就职于IBM，任软件架构师。 在此之前曾任日本东京一家软件企业的资深技术顾问。

    课程背景

    软件重构面临的背景都是相似的，程序员们為(wèi)了快速完成需求和上線(xiàn)而写出了最基本的代码，而在功能(néng)的不断扩充过程中，以打补丁的方式对代码进行扩充，中间还会面临着开发人员的变更和离职。逐渐的，代码就会越来越臃肿，渐渐的变得难以维护。

    很(hěn)多(duō)开发人员对重构有(yǒu)着严重的误解，错误的认為(wèi)重构是专门安排一个阶段来进行的，但是我们却认為(wèi)重构是持续进行的，而不是在项目结束时、发布版本时、迭代结束时甚至不是每天快下班时才进行的.重构是我们每隔一个小(xiǎo)时或者半个小(xiǎo)时就要去做的事情。通过重构，我们可(kě)以持续地保持代码尽可(kě)能(néng)干净,简单并且具有(yǒu)表达力。因此重构成為(wèi)了每个开发人员必备的基本技能(néng)，可(kě)是國(guó)内的开发人员却很(hěn)少去重构。

    那么糟糕的软件代码结构会有(yǒu)什么样的影响？首先是开发效率的降低，在糟糕架构下加进新(xīn)功能(néng)，会受之前代码的影响，可(kě)能(néng)存在意想不到的改动点和问题点，开发和调试时间都会大大增加；其次是故障率的提升，在质量低下的代码中，总是容易藏着很(hěn)多(duō)不易发现的坑，这些都会成為(wèi)故障的隐患；同时，架构也会使得需求的完成大打折扣，使得设计好的目标，因為(wèi)架构限制或者性能(néng)等原因，只能(néng)完成80%甚至更低。   

    大多(duō)数软件开发方面的培训都是关于新(xīn)系统的设计和开发,讲师教你如何从无到有(yǒu)创建出一个新(xīn)的应用(yòng)来。然而在真实的项目，许多(duō)产品如今往往依然运行在基于复杂架构设计和传统技术实现的遗留系统上，并依赖着它们，如何摸索出有(yǒu)效方法应对这些遗留系统, 已经成為(wèi)我们最需解决的问题之一。

    随着不同产品的推出、不同客户,不同版本的发布，需要维护的遗留代码越来越多(duō)，重构也就在所难免. 迄今為(wèi)止所有(yǒu)的软件系统都会变成遗留系统,并且都遭遇了缓慢,不可(kě)抗拒的腐化,因此软件开发人员不得不面对既有(yǒu)系统的混乱代码.而本课程正是告诉你如何重构既有(yǒu)的遗留系统, 如何重构代码,重构设计,重构架构.这就是本课程所要讲述的内容---重构。简言之，该课程教你如何扭转系统腐化，重构复杂遗留系统，减低维护成本。在面对一个错综复杂的，不透明的，令人费解的系统时如何慢慢地，逐步地将其变成一个简单的，有(yǒu)良好组织和设计的系统。

    课程对象

    各类软件研发中心的软件设计师、架构师, 项目经理(lǐ),技术总监,质量部门经理(lǐ)。对于重构技术怀有(yǒu)疑问和困惑，需要梳理(lǐ)解答(dá)的团队和个人，效果最佳。

    培训特色

    本课程注重实战,采用(yòng)案例贯穿方式完成实践，收集了大量的真实案例，针对项目过程中技术人员常犯的错误进行了汇总，研讨，并最终形成培训教程。本次培训从程序员的编程思维开始讲解，通过大量的真实案例，详细地介绍了重构需要注意的要点以及难点，这些知识都是讲师十几年经验的总结。本次课程1/3时间讲解核心思想，1/3时间动手重构实践，1/3点评分(fēn)析总结。

    學(xué)员基础

    學(xué)员學(xué)习本课程应具备下列基础知识：

    • 目前正在面临复杂遗留系统，必须需要维护和重构
    • 具有(yǒu)面向对象基本概念,熟悉基本设计模式

    课程内容

    以下大纲内容较多(duō)，实际授课时根据學(xué)员课前调查进行调整，并且实际授课不一定按此顺序。

    授课内容
    第一部分(fēn)   為(wèi)什么软件需要及时重构
    第一单元   软件腐烂--重构的必要性
    内容一：软件业者的反思：软件腐烂
    1.   软件腐烂（Software rot），也叫做代码腐烂（code rot）或软件腐朽（software decay）。它描述了随着时间的逝去感知到软件的缓慢衰退，其将最终导致它变得不完善、不可(kě)使用(yòng)或难以维护。
    2.   软件腐烂（Software rot）有(yǒu)两种形式：
    3.   1)隐匿的腐烂：软件逐渐不再（仍）被使用(yòng)随着剩余的应用(yòng)程序的改变变得不能(néng)用(yòng)。它已经被观察到不再被使用(yòng)的软件有(yǒu)可(kě)能(néng)一年的半衰期；
    4.   2) 活动的腐烂：软件随着不断地被修改趋向于失去它的完整性。
    5.   破窗效应与技术债務(wù)
    6.   案例演示1-通过演示大型项目，随着客户需求的变化，导致软件结构混乱，大家反思，為(wèi)什么？   你认為(wèi)软件腐烂的原因？反思你们公司的软件系统也面临这样的问题吗？
    第二部分(fēn)   重构
    第二单元   何為(wèi)重构
    内容一：重构
    1.   重构概述
    2.   何时重构
    3.   重构的误區(qū)
    4.   重构是持续进行的,不要先编写烂代码，再抽出重构
    5.   如何发现哪些地方需要重构
    6.   如何保证重构的正确
    7.   如何测试重构
    8.   通过一个小(xiǎo)案例演示重构的基本思想(什么时间重构,如何发现重构点,如何保证重构的正确性,最后如何验收)
    内容二：案例—通过实际项目演示重构
    1.   介绍项目需求情况,进行设计
    2.   阅读代码指出代码坏症状
    3.   通过重构逐步改善代码质量
    4.   通过该案例演示重构的过程，我们遇到的难处，如何解决？
    内容三：重构关键—代码的坏味道
    1.   代码坏味道概述
    2.   代码坏味道的分(fēn)类
    3.   识别代码坏味道，是重构的最重要一步
    4.   所谓重构，无非就是嗅到坏味道，然后，一小(xiǎo)步一小(xiǎo)步的改了它。问题是，很(hěn)多(duō)人对坏味道的容忍度让他(tā)们嗅不到坏味道，
    5.   案例分(fēn)析—通过真实项目的代码，分(fēn)析代码坏味道
    第二单元   重构
    内容四一：重构
    1.   重构手法概述
    2.   简要演示重构的主要手法
    3.   使用(yòng)IDE重构工具进行重构
    4.   通过案例演示如何通过重构工具完成重构
    内容二：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
    第二单元   重构难题
    内容一：重构技术难题
    1.   如何发现重构点
    2.   知道重构的目标（结果）
    3.   如何去重构—重构实践
    4.   如何保证重构的正确性-单元测试
    内容二：重构业務(wù)难题
    1.   重构手法概述
    2.   简要演示重构的主要手法
    第三部分(fēn)   重构实战1一函数相关重构
    第三单元   函数重构
    内容一：函数的重构
    1. 函数的重构
    2. 巨型函数的种类
    a) 项目列表式巨型方法
    b) 锯齿状巨型方法
    3. 分(fēn)解函数
    4. 助手方法提取
    5. 利用(yòng)自动重构对付巨型方法
    6.利用(yòng)手工重构对付巨型方法
    7. 引入感知变量
    8. 函数依赖收集
    9. 分(fēn)解助手方法和方法对象
    10. 通过案例介绍長(cháng)函数的重构最佳实践
    第三单元   函数策略和技巧
    内容一： 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
    第四部分(fēn)   重构实战2一类重构
    第四单元   类重构
    内容一：重构案例—该案例重点巨大类的重构
    1. 重构大类
    1. 对象的职责重构
    2. 职责的识别
    a)   方法分(fēn)组
    b)   观察隐藏方法
    c)   寻找可(kě)以更改的原因
    d)   寻找内部关系
    e)   寻找主要职责
    f)   接口分(fēn)离—接口隔离原则
    3.   提取类和接口
    4.   通过案例介绍如何重构巨大的类
    第五部分(fēn)   重构实战3一重构到模式
    第五单元   重构到模式
    内容一：案例---重构设计方案引入设计模式
    1. 通过项目分(fēn)析重构到模式的手段
    2. 构造Template Method
    3.   以Composite取代一/多(duō)之分(fēn)
    4. 引入Null Object
    5. 用(yòng)Adapter统一接口
    6. 用(yòng)Fatory Method引入多(duō)态创建
    5. 通过案例介绍如何重构原始设计方案，演示如何通过重构导入设计模式
    内容二：案例---重点介绍重构基本类型依赖和对应模式
    1. 通过案例學(xué)习以下重构到模式手段
    2. 以State取代状态改变条件语句
    3. 以Strategy取代条件逻辑
    4. 以Composite取代隐含树
    5. 以Interpreter取代隐式语言
    6. 转移装饰功能(néng)到Decorator
    7. 用(yòng)Builder封装Composite
    8. 重点學(xué)习案例的重构到模式的过程
    内容三：案例---重点介绍重构代码重复和对应模式
    7.通过案例學(xué)习以下重构到模式手段
    8. 构造Template Method
    9.   以Composite取代一/多(duō)之分(fēn)
    10. 引入Null Object
    11. 用(yòng)Adapter统一接口
    12.用(yòng)Fatory Method引入多(duō)态创建
    13. 重点學(xué)习案例的重构到模式的过程
    内容四：案例---重点介绍重构代码过長(cháng)/过大的类/方法和对应模式
    1. 转移聚集操作到Vistor
    2. 以Strategy取代条件逻辑
    3. 以Command取代条件调度程序
    4. 转移聚集操作到Collecting Parameter
    5. 重点學(xué)习案例的重构到模式的过程
    内容五：案例---重点介绍条件逻辑过度复杂和对应模式
    1. 以Strategy取代条件逻辑
    2. 以State取代状态改变条件语句
    3. 转移装饰功能(néng)到Decorator
    4. 引入Null Object
    5. 以Command替换条件调度程序
    6. 转移聚集操作到Visitor
    7. 重点學(xué)习案例的重构到模式的过程
    第六部分(fēn)   重构实战4一模块/组件重构
    第六单元 模块重构
    内容一：模块重构
    1. 优良的系统设计意味着我们把系统分(fēn)割成了一个个可(kě)单独部署的组件，单独部署意味着如果更改了一个组件，我们也不需要重新(xīn)部署其他(tā)组件。
    2. 组件和包坏味道
    3. 模块之间解耦
    4. 组件的内聚性实践
    5. 组件的依赖性实践
    6. 企业应用(yòng)系统组件设计最佳实践
    7. 分(fēn)析某项目,演示模块重构,如何在大型应用(yòng)系统进行模块重构
    第七部分(fēn)   重构实战5一数据库重构
    第七单元   数据库重构（该部分(fēn)根据需求，可(kě)以裁剪）
    内容一: 数据重构过程
    1. 验证数据库重构是否合适
    2. 选择最合适的数据库重构
    3. 让原来的数据库schema过时
    4. 前测试、中测试和后测试
    5. 修改数据库schema
    6. 迁移源数据
    7. 重构外部访问程序
    8. 运行回归测试
    9. 对工作进行版本控制
    10. 结束此次重构
    11.分(fēn)析多(duō)年遗留的复杂项目,演示如何重构数据库，数据库重构的一般步骤，和普通的应用(yòng)程序代码的重构的不同点。
    内容二: 数据库重构策略
    1. 小(xiǎo)的变更更容易进行
    2. 唯一地标识每一次重构
    3. 通过许多(duō)小(xiǎo)变更实现一次大变更
    4.建立数据库配置表
    5.   触发器优于视图或批量同步
    6.   选择一个足够長(cháng)的转换期
    7.   简化数据库变更控制委员会策略
    8.   简化与其他(tā)团队的协商(shāng)
    9.   封装对数据库的访问
    10.   能(néng)够容易地建立数据库环境
    11.   不要复制sql
    12.   将数据库资产置于变更控制之下
    12.   通过多(duō)个大型项目的数据库重构策略, 分(fēn)析在不同的数据库坏味道下，使用(yòng)不同的重构策略
    第八部分(fēn)   安全重构--构筑重构测试體(tǐ)系
    第八单元 单元测试-构筑测试體(tǐ)系
    内容一：理(lǐ)解单元测试
    1. 理(lǐ)解单元测试第一个单元测试
    2. 单元测试框架提供了什么功能(néng)
    3. 好的测试是什么样子的
    4. 為(wèi)什么要写单元测试，為(wèi)什么不写单元测试
    5. 為(wèi)什么要写"好"的单元测试
    6. 分(fēn)析真实项目,如何做单元测试，已经相关问题
    内容二：构筑测试體(tǐ)系
    1. 单元测试中的坏味道
    2. 让测试容易被看懂的模式
    3. 让测试容易维护的模式
    4. 让测试被信得过的模式
    5. 重构单元测试，改进代码设计
    6. 如何在集成与单元、黑盒或白盒、Mock和非Mock之间做选择?
    7.   结合多(duō)个案例项目进行分(fēn)析,分(fēn)析什么是好的单元测试
    第九单元   重构管理(lǐ)
    第九单元   重构管理(lǐ)
    内容一：安全重构
    1. 重构的恐惧心里
    2. 重构勇气
    3. 安全重构和祈祷式重构
    4. 安全重构保证
    a) 依赖编辑器
    b)签名保持
    c) 单一目标
    d) 依赖编译器
    e) 个人的能(néng)力
    f)   代码审查
    g) 单元测试
    h) 验收测试
    i)   人工测试
    5. 通过案例如何保证重构的正确性