遗留代码
从何而来
软件是如何演变成遗留代码？
- 初期，架构清晰，代码精炼，指点江山
- 中期，新功能简单在原有代码加上逻辑，页面自测，谈笑中高效完成
- 最后，另一个团队接手
- 面对难以理解的复杂代码，新增功能异常困难。
- 他们如临大敌，为避免更多的坑，选择继续在原有代码上堆积逻辑，但结果却是导致更多的bug，一首《凉凉》荡气回肠。
- 他们一边在批评着前人，一边在不堪负重的代码继续挖坑，渐渐变得与前人一样……
定义
为什么大部分系统最后都变成了没有活力的遗留系统？
因为开发人员成日奔波在填坑之中，新功能根本无暇顾及或者无法轻易添加。
系统缺失了一个最关键的东西：测试。
因为没有编写测试的代码就是遗留代码。
改变
为什么大家不愿意为遗留代码编写测试？
因为原来代码难以理解，心生敬畏且无从下手，加之bug络绎不绝，根本无暇顾及。
忍无可忍的开发者，含泪挥刀自宫——重新写一套系统。但由于缺少测试，慢慢又变成另一个遗留系统。
仿佛《恐怖游轮》般的结局。
如何破局？或许你应该先试试重构。
重构
为什么要重构
风险与收益
- 软件是高风险和多变性
- 重构可以降低成本
- 改善设计
- 更快添加新功能
- 更少产生问题
- 更快定位问题
个人成长与挑战
- 通过重构糟糕代码来培养良好习惯
- 保持既有行为不变是软件开发最有挑战的任务之一
- 我们可能无法选择好的项目，但我们可以选择好的挑战
何时重构
- 当关键代码维护不善的时候
- 当唯一理解代码的人没空的时候
- 当有信息可以揭示更好的设计的时候
- 当修复bug的时候
- 当需要添加新功能的时候
- 当需要为遗留代码写文档的时候
- 当重构比重写容易的时候
考虑问题
我们在重构时需要考虑各个方面，修改遗留代码永远是一件危险的事情。
多问问自己：
- 哪些需要修改？
- 如何验证正确完成修改？
- 如何确保没有破坏既有功能？
- 如何避免修改带来越来越难以理解的代码？
正确重构
- 从已有系统中学习，只重构熟悉的功能
- 循序渐进，一次不要重构过多
- 在遗留代码中添加测试，单元测试是重构最有力的保障
- 有更好的理解后对一个实现进行重新设计
单元测试
好的单元测试
- 快速反馈，十分之一秒都算慢
- 重构后能够快速定位问题所在
- 以行为作为单元，而不是代码量
- 一个独立可验证的行为
- 产生可观察的影响
- 不与其他行为耦合
- 行为不变，测试也不变
- 成为活文档
- 单元测试也是代码，与其他代码同等质量要求
bad：testConstructor good：testRetrievingValuesAfterConstruction
编写策略
全新功能
采用测试驱动开发（TDD），需要我们改变习惯——从做什么开始，再关注怎么做。
编写步骤：
- 先设计测试，可在任何时候进行
- 设计接口，确定方法名称、收入参数、返回值
- 编写测试
- 实现，重构
遗留代码
解除依赖性以使遗留代码改动更容易，所以要编写测试，往往需要先修改代码。
编写步骤：
- 确定改动点
- 找出测试点
- 解依赖，为测试创造空间
- 编写测试
- 修改，重构
关于bug
最后我们聊聊bug，解决bug最好的方法，就是避免Bug的出现，这就要求我们编写高质量代码。
如果功力不够，那就尽早发现bug，依赖持续集成，自动化测试。
设计时打印关键日志信息，让bug更容易找到。
每发现一个bug，就当作一项缺失的测试。
利用发现的缺陷修正流程，不断从错误中学习。
后续
后续章节将重点关注如何对遗留代码进行测试，为重构保驾护航。
网友评论