如何在遗留代码基础上开发
|
对于大多数开发者来说，在遗留代码基础上开发是日常工作的一部分，毕竟从头开始创建全新系统的机会不是很多。架构师、《漫谈设计模式》作者刘济华结合自身的实际经历分享了如何在遗留代码基础上开发的经验。
刘济华首先指出，大多数系统是构建在之前的遗留系统之上的，在开始，很难把遗留系统直接丢弃，特别是一些业务逻辑非常复杂的金融电信系统。 这些代码往往有如下特点：
但是这些代码能够完成当时的功能，直接抛弃这些代码，重新开发将会耗费很大的资源，且不一定成功，如果新的需求不断变化，往往没有时间来重新开发这些代码。而这些遗留代码的功能没有完善的文档说明，甚至没有。 在此现状下，如何改善这些代码，将是考验程序员和一个团队的智慧。
接着，刘济华分析了对于遗留代码取舍的亲身经历。
具有性能瓶颈的遗留系统——曾经遇到过一个应用服务，是C语言写的，周围其他系统都是采用 Java 开发，与此系统的交互都是采用非标准的协议完成，而且此系统处于比较核心的位置，但是维护非常复杂，不稳定，访问压力大是经常宕机，无法水平扩展，只能提高硬件设备水平等方式考虑。
在原有协议基础上开发，使其具有水平扩展能力，代价和开发一套标准协议的实现没有任何区别，往往会带了协议不够完善所产生的问题。于是，我们为其开发新的标准协议，WS，MQ 等等，然后在标准协议上负载均衡实施水平扩展，非常方便。
随着后来的发展，此遗留代码也慢慢被新开发系统取代，期间经历了新系统和旧系统同时存在，此时新系统未完全具有旧系统的全部功能，这部分功能还是使用旧系统完成，只不过在原有均衡负载层多了层查找和分配的，后来到旧系统完全取代。此过渡还算平顺。
功能性改造型系统——大多数就是这种系统，保留的话，代码极其复杂，维护麻烦，丢弃的话，无法一夜之间写出新的系统。曾经接手了一个开发失败的项目，包括代码和文档都未完善，如果重新来过，终究不划算，后来在此系统上进行改造，特别是花了大量时间写单元测试，保证代码测试覆盖率极高，这样一边熟悉代码，一边重构代码，系统的健壮性发生根本改变，前提是有时间。这只是特例。很多时候遇见的系统，同样测试代码很少，在添加新的功能和修复错误（Bugs）时，为这些能够接触到的代码完善测试，新代码必须测试覆盖率必须很高，经过 4 个月，，此系统代码覆盖率已经达到 50% 以上。以后的迭代开发越来越快。
那么如何在在遗留代码上编程呢？刘济华觉得首先要找到代码修改点：
遗留系统代码往往测试少，或者没有，导致软件开发者对软件发布没有信心。但是为所有的遗留代码写单元测试，初始代价非常高，在添加一个很小的功能时，并没有时间大动干戈。
如何找切入点呢?刘济华总结了几种情况：
修改一处代码即可，这个时候非常简单，修改代码处即为切入点，找到这处修改即可，为此处代码写完善的单元测试代码，特别是对于输入条件和测试条件尽量能够完整测试
修改多处代码，位置分散，并且修改代码如果有多种方案，我们找出最少修改代码的地方，而不是最佳的修改方式，很多时候，此时最佳的代码修改会修改很多代码，导致测试代码无法一下子完善，另外，此时认为的最佳方案随着时间的推移，或许又是糟糕的代码，所以没有必要花费更多的精力在上面，当然也可以选择比较中庸的方式。
在修改时需要一些技巧，其中包括：
如何保证质量呢？刘济华建议：
|
