遗留项目: 任何已存在的, 难以维护或难以扩展的项目
这本书总体来说还不错, 值得一读
第一章: 了解遗留项目中的挑战
特征:
遗留代码:
- 没有测试和无法测试的代码: 难以
确认
- 不灵活的代码: 难以修改和扩展
- 被技术债拖累的代码:
遗留基础设施:
- 开发环境: 难以搭建/搭建成本高, 构件工具/项目中构件脚本/文档中大量的手工步骤
- 过时的依赖: 没有定期维护, 带来了后期升级维护的成本和风险
- 异构环境: 不同环境不能保持一致, 这种环境不一致带来的风险(无法模拟生产环境)
遗留文化:
- 害怕变化: 缺少信息 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. 小型为佳
保持代码库小型轻量;
