遗留项目: 任何已存在的, 难以维护或难以扩展的项目

这本书总体来说还不错, 值得一读

第一章: 了解遗留项目中的挑战

特征:

• 老旧
• 庞大
• 继承而来
• 文档不完善

遗留代码:

• 没有测试和无法测试的代码: 难以确认
• 不灵活的代码: 难以修改和扩展
• 被技术债拖累的代码:

遗留基础设施:

• 开发环境: 难以搭建/搭建成本高, 构件工具/项目中构件脚本/文档中大量的手工步骤
• 过时的依赖: 没有定期维护, 带来了后期升级维护的成本和风险
• 异构环境: 不同环境不能保持一致, 这种环境不一致带来的风险(无法模拟生产环境)

遗留文化:

• 害怕变化: 缺少信息 1)哪些功能不再使用可以移除? 2)哪些bug可以被安全的修复 3) 改动之前应该咨询哪些用户? -> 结果: 保持现状是最安全的选择; 纯粹的风险, 忽略了带来的好处;
• 知识仓库: 知识的匮乏; 团队知识的共享和传承; 1) 缺乏面对面沟通 2)代码是我的 3)忙碌的面孔

第二章: 找到起点

恐惧: 遗留系统带来的不确定性; 对未知的恐惧: 更改了一行代码可能会破坏一些根本不相关的东西

探索性重构: 尝试重命名方法, 在两个类之间移动方法, 引入新的接口, 添加注释等等小变更

好处:

• 增加你对代码的理解, 了解越多, 掌握的信息就越多, 恐惧越少;
• 提高的代码的可读性;
• 在版本控制系统/IDE/编译器/其他开发人员等帮助下, 更简单且安全

特征测试: 验证系统指定部件当前的行为

收集软件的有用数据:

• 静态代码分析工具 / bug查找工具
• 性能: 性能测试+生产环境性能监控
• 错误计数: 例如500错误
• 对常见的任务计时: 1) 从头开始搭建开发环境时间 2) 发布或部署项目所花的时间 3) 修复一个bug的平均时间
• 版本库中修改最多的文件

静态分析工具

• FindBugs: 查找java中潜在的bug -> 修复关键bug
• PMD: 是否遵循最佳实践 -> 修复
• CheckStyle: 修复风格问题, 提高可读性

第三章: 准备重构

重构时始终记得组织的目标

两种角色:

• 传统主义者: 不要碰任何东西, 强烈反对任何形式变化的开发者; 认为重构会带来不必要的风险;
• 反传统主义者: 所有东西都要重写; 厌恶遗留代码; 热衷于提高代码质量, 但是可能过于激进;

需要通过沟通, 确保团队每个人对项目有相同的理解, 统一目标及计划;

获得组织的批准

选择重构的目标: 三个维度评估, 难度/风险/价值

• 容易实现的目标: 风险=低, 难度=低
• 痛点: 价值=高

重构还是重写?

• 不应该重写的情况: 1)风险 2)开销 3)任务总是超出预期时间
• 重写的好处: 自由/可测试性
• 重写的必要条件: 1) 尝试过重构并且失败了 2) 编程范型的转变
• 第三种方式: 增量重写, 将重写分成若干个较小的阶段, 每个阶段都应该提供业务价值, 应该可以在任何给定阶段之后停止项目, 并且仍然能获得一些好处.

第四章: 重构

有纪律的重构:

• 把重构和其他的工作分开
• 依靠IDE的refactor!
• 依靠版本控制系统

常见的遗留代码的特征和重构

移除陈旧代码:

• 被注释掉的代码
• 死代码: 绝对不会被执行的代码
• 僵尸代码: 那些功能已经去掉或者不再存在
• 过期代码: 时间依赖/ab test/活动等

移除有毒的测试:

• 没有测试任何东西
• 脆弱的测试:
• 随机失败的测试

第五章: 重搭架构

重搭架构是比方法和类更高级别的重构. 可以把它想像成大型的重构, 将大型应用拆分为多模块

好处:

• 通过模块化内建质量
• 良好的涉及保障可维护性
• 通过独立达到自治

涉及:

• 单体应用拆分为多模块
• 前后端分离
• 微服务

其他

开发环境自动化:

• 一个好的README
• vagrant/ansible/docker等实现开发环境自动化

多环境一致性: 测试环境/预发布环境/生产环境

开发/构建/部署过程自动化

Linux 项目持续成功: 公开和坦诚沟通的文化, 重视CodeReview

主题

1. 源代码并不是项目的全部

2. 信息不能是自由的

文档: 信息丰富/易于编写/易于发现/易于阅读/可信赖

促进沟通: 代码评审/结对编程/技术访谈/向其他团队展示你的项目/黑客日

3. 工作是做不完的

维护代码库质量十一个永无止境的任务; 需要保持警惕并在质量问题一出现就解决它

定期进行代码评审 / 破窗理论

4. 自动化一切

自动化测试/自动化构建/自动化部署等

• 使你的生活更加轻松
• 是你的接班人的生活更加轻松

5. 小型为佳

保持代码库小型轻量;