第一部分 为什么软件需要及时重构 |
第一单元 剖析软件质量不断下降的根源 |
质量不断下降的表现:
- 程序代码越来越乱
- 软件维护成本越来越高
- 软件变更越来越困难
- 无法进行新技术的改造
以往采取的措施:
- 头痛医头,脚痛医脚
- 抛弃掉重新编写
- 因担心未来变化而做的过度设计
带来的问题
- 团队成员越来越多但效率却越来越低
- 测试变得越来越困难而任务繁重
- 软件系统越来越笨重而不适应未来变化
分析与反思
案例分析:一个遗留系统的演化过程
- 起初的设计
- 随后的变更
- 质量不断下降的过程
软件质量下降的根源:
- 软件总是因变更而变得越来越复杂
- 软件结构已经不再适应复杂的软件需求
- 必须要调整软件结构以适应新的软件需求
软件是因需求变更而质量下降吗?
案例分析:推演软件变更的设计过程
应对软件变更的最佳方式:两顶帽子
- 重构原有代码以适应新的需求
- 实现新的需求
案例:演示两顶帽子的设计过程 |
第二单元 高质量的软件设计过程 |
以往软件设计的过程:
- 演示以往软件设计的过程
- 剖析以往软件设计的问题与风险
小步快跑模式的开发过程:
- 用最快的速度开发一个最核心的功能
- 让第一个版本运行起来并可以验证
- 在第一个版本的基础上不断添加功能:
- 每次只添加一个很简单、很单一的功能
- 每次以两顶帽子的方式添加新功能
- 运行、调试与验证
- 重复这个过程添加下一个功能
- 复杂的系统就是由一次次正确开发的不断积累而成
案例:演示小步快跑的开发过程
小步快跑解决的问题:
- 复杂功能有效地解耦
- 代码编写总是可测试与验证
- 简化设计与思考的复杂度
- 适时重构以避免软件退化
测试驱动设计
- TDD vs. 后测试开发
- 案例:演示测试驱动设计的过程
- 测试驱动设计的优势
- 实践测试驱动设计的难题
讨论:自动化测试脚本应当由谁来写?
练习:运用小步快跑的方式设计一个软件 |
第二部分 重构的概念 |
第三单元 何为重构 |
软件重构的概念
- 重构是一系列代码的等量变换
案例:一个Hello World重构过程
- 重构的保险索:自动化测试
案例:Hello World的自动化测试过程
- 软件修改的四种动机——重构的价值
- 一个真实的谎言——重构的误区
- 重构的主要方法与技巧
案例分析:重构一个大型遗留系统
- 重构第一步:分解大函数
超级大函数及其危害
案例:演示大函数产生的过程
案例:演示抽取方法操作步骤
实践抽取方法会遇到的问题和解决方案
- 重构第二步:拆分大对象
超级大对象及其危害
案例:演示超级大对象的产生过程
案例:演示抽取类的操作步骤
讲解单一职责设计原则
案例:演示“分久必合,合久必分”的重构过程
- 重构第三步:提高复用率
讲解顺序编程及其危害
“不要重复代码”原则
案例:提高代码复用的6个方法
案例:演示新增代码时的代码复用过程
用静态检查工具检查重复代码
- 重构第四步:可扩展设计
过度设计 vs. 恰如其分的设计
讲解“开放-封闭”的设计原则
案例:讲解可扩展设计的4个方法
案例:讲解新增代码的可扩展设计过程
- 重构第五步:降低耦合度
案例:讲解接口、实现与工厂模式
案例:讲解外部接口解耦与适配器模式
案例:讲解继承泛滥问题与桥接模式
案例:讲解方法解耦与策略模式
案例:讲解过程解耦与命令模式
案例:讲解透明扩展与组合模式、装饰者模式
- 重构第六步:系统分层
反思软件架构需要怎样的分层结构
遗留系统如何拥抱需求变化
遗留系统如何应对技术变革
- 重构第七步:领域驱动设计
领域驱动设计的概念
讲解领域模型分析方法
讲解原文分析法与领域驱动设计
讨论:如何制定重构项目计划
练习:重构一个小程序并编写测试脚本
|
第四单元 关于重构的讨论 |
什么时候重构
- 重构是一种习惯
- 重构让程序可读
- 重构,才好复用
- 先重构,再扩展
- 紧急任务时的重构
测试的困境
- 重构初期的困局
- 解耦与自动化测试
- 建立自动化测试体系
重构的评价
- 评价软件质量的指标
- 评价软件质量的工具
|
第三部分 系统级的重构项目 |
第五单元 遗留系统的技术改造难题 |
技术改造的难题 一些大型遗留系统已经运行维护十年以上,现在面临着技术改造的难题:
- 程序越来越乱:代码在退化,软件质量持续下降,维护成本越来越高;
- 面临技术改造:一直在犹豫改还是不改,但现在到了不得不改的时候了。
以往的解决方案:
- 修修补补,遇到什么问题就解决什么问题:
存在的问题:
a.始终治标不治本,不能从根本上解决许多问题;
b.有过一些改造,但不敢尝试真正的技术改造,越老的系统技术越落后
存在的问题:面临着被市场淘汰的绝大风险
- 彻底丢弃原有系统重新开发,从而快速摆脱以往的技术债务
存在的问题:
原系统运行维护十年以上,积累大量繁复而细微的业务需求与程序逻辑,但在重做过程中都遭到遗失,给项目带来巨大的风险
问题的实质:
- 面临巨大市场的压力,改造是想做不想做都得做的事情了;
- 原系统中积累大量繁复而细微的业务需求与程序逻辑,既不在设计文档中,也不为现有的维护人员所掌握,但一旦遗失却严重后果;
- 一边在技术改造,一边还有新的需求需要维护,意味着改造中的新系统,在还未替代老系统前,还要不断与老系统同步
正是有了如此多的难题与风险,使得旧系统改造面临进退两难的困境。
演化式重构解决方案:
- 演化式地对原系统进行重构,渐进式地进行优化改进
不是丢弃原系统,而是从原系统开始,运用重构方法进行一小步一小步的优化与调整,使技术改造过程变得平滑
- 培训、指导与审查并举,切实提高代码编写质量
首先对人员进行代码质量与重构的培训,制订代码规范与静态代码检查。在开发初期加强对每项设计的指导,之后组长责任制进行代码审查。
- 组件开发-测试为一体的团队
一边改造,一边编写自动化测试脚本,让改造过程随时处于质量监控之下
- 优化与维护并行开展,让改造工作快速起效
制订迭代式计划,每完成一次改造就发布一个可运行版本。之后的运行维护在该版本的基础上开展
- 平台建设与系统重构并行开展,加快改造速度
分成平台组与重构组并行开展工作,一边在搭建新的技术开发平台,一边运用重构在优化原有系统,最终实现原有系统向新开发平台的代码迁移
|
第六单元 系统级软件重构过程 |
案例分析:演化式重构的改造过程:
- 概念及解决的问题
演化式重构的概念
建立领域驱动设计的过程
- 模块的选择与迭代项目计划
先选择易上手、快速起效的模块开始改造
再选择最核心、最关键的模块进行改造
制订迭代式技术改造项目计划
- 组建一个开发-测试为一体的团队
测试人员与开发人员同时开始工作
改造初期的自动化测试过程
逐渐编写自动化测试程序的过程
- 平台建设与系统重构并举
重构组:
一边在重构,一边在升级维护上线,既使改造工作快速起效,又使重构的成功以最快的速度得到验证,降低改造风险
平台组:
构建基于领域的轻量级系统架构,既为旧系统代码移植创造条件,又为技术的更迭降低成本
- 平滑地代码移植
代码移植的条件:
1)旧系统完成了代码重构,实现业务代码与技术代码的有效解耦;
2)新平台构建了一个基于领域的系统架构。
代码移植过程:
1)将旧系统中的业务领域层有效提取出来;
2)将业务领域代码放入新平台中
3)完成其它的配置、接口、前端界面等工作
4)运行、调试、测试
改造的效果:
- 实现领域驱动设计,拥抱未来需求的变化
- 建立自动化测试体系保障软件质量
- 更加灵活而快速地应对未来技术的更新
讨论:系统级重构的经验与分享
|