软件产品架构腐化以后如何维护

软件产品经过时间久了，不断的修改，打补丁，就会破坏原来的架构，导致后面维护都非常难。

那么在维护当中，有没有好的经验和办法，我今天就给大家分享几点好的经验供大家参考。

第1个经验就是，新老代码要进行隔离，也就是说，新代码要跟老代码隔离开。

为新代码创建新的文件，心的类，新的配置，如果一定在老的类的改的时候，必须增加新的函数，如果新增函数里也解决不了必须在老的类里面老的函数那么就做好注释和代码块的隔离，这样来讲就通过代码块，函数，类，文件，配置把新老代码独立开了，这样就会在新老功能当中做好区分，这样的话就不容易出问题，质量，效率都会高。

第2个经验，就是做局部重构

就是选择子系统或者是模块进行重构，当对于某个子系统或者模块考虑的比较清楚了，有了好的重构方法了，就可以把这个模块或者子系统进行重构。

那么重构要注意哪些事项呢？

1）重构的时候，安排尽量少的人，1~3个人进行模块或者子系统的优化比较好，而不是安排很多人，很多人就容易把这个事情做乱了，效率会很低。

2）做重构的设计，重构设计很重要，要达成这个重构的方案的共识，而不是随便一个方案就去重构了。

3）做特性梳理，这个特性梳理是为了下一步做的，就是这个重构，一定要兼容以前的特性，那么就必须做特性梳理。

4）做兼容性测试，要保证重构后的系统跟原来的系统是完全一样的功能，性能，稳定性都是一样的或者是比原来更好的，而不能说丢了特性，那都不是原来的系统了那就不要重构了。

第3个经验，做全局重构

全局是在业务有巨大变化或者是在软件的基础架构有巨大变化的时候进行的，比如说，原来你是做的是单体的，现在要做微服务架构那么就有必要做这个全局的重构。

全局的重构，实际就是大一点的局部重构，那么它的要求是一样的，也要做重构的设计，特性的梳理，兼容性的测试。只是说安排的人会多一点，尽量还是每一个模块每一个子系统1~3个人，不宜过多，多了的话，效率就会低下。效果可能还不好。

第4个经验，就是重用老代码

程序员的都有一个思维，希望是原创的。也就是说他希望代码都是他亲手敲进去的，而不是利用别人的代码，实际上这是一个很不好的思维。

应该做到尽量重用以前的代码，因为老的系统虽然经过长时间的修修补补以后，架构没那么好了，代码看着没那么清爽了，但是，它里面有很多局部的代码，局部的算法是非常好的，那这一部分一定要把他继承下来 重用下来。前面讲到的重构设计，其中很大一部分就是包括利用原来代码的这个设计，原来代码的经过时间的磨练的质量是非常高的，性能也非常高的可靠性也非常好的，如果把她浪费掉的是非常可惜的，重用既保证了质量又提高了效率，可以把精力放在有必要重构的地方做到更好的重构。

希望都能用好老系统，使老系统老树焕发青春，能够为企业带来更多的商业价值。