遗留系统改造-开篇

遗留代码

从何而来

软件是如何演变成遗留代码？

• 初期，架构清晰，代码精炼，指点江山
• 中期，新功能简单在原有代码加上逻辑，页面自测，谈笑中高效完成
• 最后，另一个团队接手
  • 面对难以理解的复杂代码，新增功能异常困难。
  • 他们如临大敌，为避免更多的坑，选择继续在原有代码上堆积逻辑，但结果却是导致更多的bug，一首《凉凉》荡气回肠。
  • 他们一边在批评着前人，一边在不堪负重的代码继续挖坑，渐渐变得与前人一样……

定义

为什么大部分系统最后都变成了没有活力的遗留系统？

因为开发人员成日奔波在填坑之中，新功能根本无暇顾及或者无法轻易添加。

系统缺失了一个最关键的东西：测试。

因为没有编写测试的代码就是遗留代码。

改变

为什么大家不愿意为遗留代码编写测试？

因为原来代码难以理解，心生敬畏且无从下手，加之bug络绎不绝，根本无暇顾及。

忍无可忍的开发者，含泪挥刀自宫——重新写一套系统。但由于缺少测试，慢慢又变成另一个遗留系统。

仿佛《恐怖游轮》般的结局。

如何破局？或许你应该先试试重构。

重构

为什么要重构

风险与收益

• 软件是高风险和多变性
• 重构可以降低成本
  • 改善设计
  • 更快添加新功能
  • 更少产生问题
  • 更快定位问题

个人成长与挑战

• 通过重构糟糕代码来培养良好习惯
• 保持既有行为不变是软件开发最有挑战的任务之一
• 我们可能无法选择好的项目，但我们可以选择好的挑战

何时重构

• 当关键代码维护不善的时候
• 当唯一理解代码的人没空的时候
• 当有信息可以揭示更好的设计的时候
• 当修复bug的时候
• 当需要添加新功能的时候
• 当需要为遗留代码写文档的时候
• 当重构比重写容易的时候

考虑问题

我们在重构时需要考虑各个方面，修改遗留代码永远是一件危险的事情。

多问问自己：

• 哪些需要修改？
• 如何验证正确完成修改？
• 如何确保没有破坏既有功能？
• 如何避免修改带来越来越难以理解的代码？

正确重构

• 从已有系统中学习，只重构熟悉的功能
• 循序渐进，一次不要重构过多
• 在遗留代码中添加测试，单元测试是重构最有力的保障
• 有更好的理解后对一个实现进行重新设计

单元测试

好的单元测试

• 快速反馈，十分之一秒都算慢
• 重构后能够快速定位问题所在
• 以行为作为单元，而不是代码量
  • 一个独立可验证的行为
  • 产生可观察的影响
  • 不与其他行为耦合
  • 行为不变，测试也不变
  • 成为活文档
• 单元测试也是代码，与其他代码同等质量要求

  bad：testConstructor
  good：testRetrievingValuesAfterConstruction
  

编写策略

全新功能

采用测试驱动开发（TDD），需要我们改变习惯——从做什么开始，再关注怎么做。

编写步骤：

• 先设计测试，可在任何时候进行
• 设计接口，确定方法名称、收入参数、返回值
• 编写测试
• 实现，重构

遗留代码

解除依赖性以使遗留代码改动更容易，所以要编写测试，往往需要先修改代码。

编写步骤：

• 确定改动点
• 找出测试点
• 解依赖，为测试创造空间
• 编写测试
• 修改，重构

关于bug

最后我们聊聊bug，解决bug最好的方法，就是避免Bug的出现，这就要求我们编写高质量代码。

如果功力不够，那就尽早发现bug，依赖持续集成，自动化测试。

设计时打印关键日志信息，让bug更容易找到。

每发现一个bug，就当作一项缺失的测试。

利用发现的缺陷修正流程，不断从错误中学习。

后续

后续章节将重点关注如何对遗留代码进行测试，为重构保驾护航。