软件维护的噩梦

我们很多时候可能不是那么幸运的被叫来做软件开发工作，而是做现有软件的维护。比如前人跳槽了，或是安排做其他工作去了，剩下的已交付的软件就需要人来继续维护。这可是一个苦差事，首先要看得懂前辈的代码，然后就是软件支持、改bug、改功能、加新功能，等等。反正就是做痛苦的修修补补的工作。

比起软件开发来，软件维护简直就是无聊透了，首先不能出成绩，虽说维护庞大的代码不比开发来的容易，先前软件架构不好，维护性差，那你工作量就大了，可你做好了也就是个维护工作，没有创新，没功劳，如果有功劳，那也是前人栽树后人乘凉啊，前辈们系统设计的好。其次是工作内容很枯燥，谁愿意费尽心机去看懂别人的代码呢？更何况有的代码是没有文档，没有注释，没有良好的命名规则的三无代码。即使有文档，文档基本很久没有更新了，和代码对不上号。看这种代码，改这种代码，简直就是对自己的耐心的一种折磨和考验。

更加可怕是，尽管设计说明书上描述的架构设计的如何精巧灵活，结果事实往往不是这样，在新的功能需求面前不堪一击。很多时候改了一个小地方，结果会触动其他的隐藏的很多神经，任何修改你都要小心翼翼。除了原来的程序员，没有人确切的知道某某功能点需要修改几个地方，哪儿和哪儿是相互关联的，这个功能会影响那个功能。有的时候甚至连需求功能点列表都没有留下。这简直就是软件维护的噩梦。

最后的结果就是：“钱基本花光，人基本跳光，甲乙双方感情基本破裂。”

其实从软件生命周期来讲，任何一个软件总有一天，它的架构会越来越不能满足新的需求，会走到尽头的时候。但不到万不得已，客户不会抛弃原来系统而花大价钱去开发一个新系统的。所以讨论如何进行软件维护还是有一定意义的。

 

难道就没有维护性好的系统？

我见到的一些老系统运行了几十年很稳定，维护的也很好，(可能刚上系统的一两年会比较痛苦吧，但从几十年来看很稳定) 比如银行和电力的老系统，最后直到前几年银行大集中的时候才上了新系统。难道他们的系统那么强悍吗？难道他们没有新需求出现吗？错了，其秘密在于银行核心的业务基本没变，所以软件的核心价值和功能没有变，变的只是些小的边缘的需求，银行会不断在上一些非核心的业务和系统，但前提是不修改不影响核心业务系统的运行。我想这一点对做软件开发和维护的人来说有点启示。如何把不经常变的东西挖掘出来？起初设计系统的时候，就应该集中在核心业务需求上，因为那才是这个软件的最大价值和核心。核心价值不能变。对这个核心业务价值的设计应该具有良好的扩展性、维护性、和稳定性。当然，全面细致的文档，及时更新，都是非常重要的，能抵御人员流失的风险。

 

从维护重新认识软件生命周期

• 软件维护通常占到软件总成本的40%-80%，维护可能是整个软件生命周期中最重要的阶段。
• 功能增强(Enhancements)可能占到60%的软件维护工作。
• 软件维护是一个解决方案(Solution)，而不是一个问题(Problem)。
• 理解现有的软件是软件维护中最困难的工作。
• 复杂的逻辑、功能和配置都降低了软件的维护性。

 

软件维护中的创新：重构

被分配到做软件维护，其实也能够学到很多东西，也可以在维护中间思考如何进行重构。因为任何一个成功的软件都是不断进行重构才真正成功的，从1.0，到2.0，重构到3.0，甚至到8.0，任何时候都不要以为软件已经完美，任何时候都可以进行重构。当软件千疮百孔，不堪重负，对新增需求举步维艰的时候，就是重构的时候了。但重构要注意两点：

首先是重构要保持系统的核心价值不变。例如，老的软件的最大卖点是体积小，启动快；这个对用户的核心价值在以后的重构中不能丢，否则就会失去用户。

其次是重构必须要注意风险。重构的前提是要对老系统非常了解，功能点、架构、实现细节、依赖关系、强项与弱项、相关文档、业务逻辑等，都要非常了解。另外一个重构的前提是有质量保证，单元测试、功能测试、回归测试，否则任何试图重构和解耦系统、试图提高代码结构、性能和维护性的努力都会带来极大的风险。