我觉得可能还是要细分。
遗留系统，如果一切运行正常，本来就没必要升级维护。
需要维护了，一定是有了新的需求不能满足。
那重点还是应该看看新的需求有什么问题。
比如，一个系统，原来预设承载20w用户，目前用户数达到100w了，性能出现瓶颈，那这个是一个性能问题，可以考虑不动原系统，而是购买设备，把原系统Copy4份，再在Server前级上做个动态负载均衡，就解决问题。
如果是缺乏某个功能，那这个功能完全可以单独开发一个Service，放到另外一个Server去跑，最后在遗留系统上添加一条信令，把该功能转向到新的Server去处理就好了，也没必要动原有系统。
做了这么多年程序，越来越觉得商业软件的开发，其实测试比开发还重要。稳定性压倒一切。
单机系统也差不多，就是尽量不要动已经成熟的模块。
一个系统，做出来，可能三个月就好了。
但要是能宣布满足需求，稳定运行，达到运营级的产品，不试运行一年以上，恐怕谁都不敢说这个话。
因此我觉得，商用软件，最值钱的，就是这个长期运营的稳定结果，而不是软件本身。
因此，我们对于已有系统，原则上只做增量维护，对于新增功能，或者超出原有设计的loading，都只做分流和增补，永远不会去打破老系统的平衡性和完整性，这才是一个慎重的解决之道。
对于遗留系统，我建议首先尊重其成果，再谈如何增补，永远不要删改。
毕竟，每个公司都有自己的积累，我们新进公司的新人，其实是用这些老系统赚的钱在养活，总不能自己砸自己家的锅吧？
遗留系统，如果一切运行正常，本来就没必要升级维护。
需要维护了，一定是有了新的需求不能满足。
那重点还是应该看看新的需求有什么问题。
比如，一个系统，原来预设承载20w用户，目前用户数达到100w了，性能出现瓶颈，那这个是一个性能问题，可以考虑不动原系统，而是购买设备，把原系统Copy4份，再在Server前级上做个动态负载均衡，就解决问题。
如果是缺乏某个功能，那这个功能完全可以单独开发一个Service，放到另外一个Server去跑，最后在遗留系统上添加一条信令，把该功能转向到新的Server去处理就好了，也没必要动原有系统。
做了这么多年程序，越来越觉得商业软件的开发，其实测试比开发还重要。稳定性压倒一切。
单机系统也差不多，就是尽量不要动已经成熟的模块。
一个系统，做出来，可能三个月就好了。
但要是能宣布满足需求，稳定运行，达到运营级的产品，不试运行一年以上，恐怕谁都不敢说这个话。
因此我觉得，商用软件，最值钱的，就是这个长期运营的稳定结果，而不是软件本身。
因此，我们对于已有系统，原则上只做增量维护，对于新增功能，或者超出原有设计的loading，都只做分流和增补，永远不会去打破老系统的平衡性和完整性，这才是一个慎重的解决之道。
对于遗留系统，我建议首先尊重其成果，再谈如何增补，永远不要删改。
毕竟，每个公司都有自己的积累，我们新进公司的新人，其实是用这些老系统赚的钱在养活，总不能自己砸自己家的锅吧？
呵呵，一家之言哈，欢迎大家批评。
本文转自 tonyxiaohome 51CTO博客，原文链接：http://blog.51cto.com/tonyxiaohome/198493 ，如需转载请自行联系原作者
