浅谈老系统维护

今天聊一个老话题，如何维护一个老系统，尤其是一个很重的老系统，少则3-5个年头，多则7-8个年头，第一版代码早已不知是哪些人编写，

这个老系统迎来送走了一批有一批程序员，可谓是看尽公司的浮沉沧桑，如今，它既是公司的功臣，也是公司的包袱， 每个公司都或多或少有一些样的老系统。

开发新的项目替代老系统，需要很大的人力物力，还要经过一段时间去磨合它的稳定性，新的就一定比旧的好用吗？项目失败的概率依然很大，没人愿意去承担这样的风险。相比之下，维护一个老系统，面对新的需求，升级老系统，虽然保守，但很稳健，风险很低。怎么说呢？存在即有道理，否则早就推翻重来了。

这个时候，自然就苦了老系统的维护人员。

你能想象，一个既没有数据库表设计说明书，没有任何需求和设计文档，代码风格迥异没有几个注释，同一个开源框架多版本共存，没有任何分层设计的老系统带给维护人员的是什么吗？

不说，希望你懂。

笔者最近也在维护一个这样的系统，既然没得选，只能接受，还要在之中找出乐趣，获得经验，取得进步，不是吗？

项目背景：开发平台，其他项目组开发的项目都是以这个开发平台做的，而我的任务就是不停地给这个开发平台打补丁加功能，还要为其他项目组提供平台方面的支持。

感悟之谈，仅供参考。

1、如果你不想被后边接手这个项目的人骂，请在修改的时候，一定要注释上修改说明，越详细越好，比你修改的代码行数还要多都不为过。甚至你可以修改点同一个目录下附上一个说明文档，相信后来人会对你感恩戴德的。

2、没有数据库说明书，没有文档，没有注释，那怎么改？先别苦恼，很多程序员都和你面对同样的问题，公司招你不是让你喝茶看报纸的。遇到这样的问题，镇定！先和提需求和提bug的人员深入的沟通：第一、一定要改吗？能不能说服客户不改。讲清其中的利害关系。第二、客户买你的软件，自然就是上帝，没办法必须改，那好，落实到文字上，让客户把自己的问题描述清楚，开发人员能看懂，两者进行过切实的沟通。如果开发人员面对的是实施人员，就更要多次深入的沟通，防止做无用功，出来的东西不是客户要的玩意，得不偿失。

最后沟通，必须改，改成什么样子，心里有数了，再开始动手，沟通，沟通，还是多沟通。

3、备份，还是备份。不要以为有SVN，你就高枕无忧，做梦吧。因为很多时候，SVN里面的代码跟客户现场部署的根本不是一个东西，很多修改都是在客户现场做的，压根就没有反馈到公司SVN服务器上。你以为修改错了，SVN里还有，再下载一份就OK了，压根就不是那么回事。所以，修改之前，请手动备份，并写好备份日期，当前处于什么版本，为什么备份，如何还原该备份，操作人。

4、有时候有人会就你维护的项目问一些问题，日子久了，重复的问题总是一遍一遍的被问到，那好吧，你会想我写文档，放到公司内网上，这样我就省事了，我只能说，你只做了一半。慢慢地，你会发现，大家还是会问你相同的问题，明明那里有文档，大家不去看，依然直接电话过来问题。原因呢？第一，大家不知道那里有文档；第二，不如直接问人来得迅速，因为你每次都一一解答了。所以，你写了文档要通知大家，如果大家依然问你，那好，你可以尝试告诉他，稍等下，我给你发封邮件，千万不要发文档，直接发一个链接就好了，顺带温馨提醒一句，以后遇到问题，可以去哪里找。大家的习惯有时候是你惯出来的，同时也是你培养的。

5、接下来再说点技术细节上的吧：1）打补丁，尽量写成独立的函数，在该插入的地方调一下，少动原来代码，就是少引入bug。2）尽量避免全局变量，引入全局变量对于系统来说是很危险的，很多程序员同胞都应该理解。3）每个版本，你都修改了什么，要有个文档说，这样你想还原回去或者找针对某个客户的版本会很从容。4）不要急着向所有的项目推出这个补丁，先先推一个项目组，经过一段时间证明补丁稳定，再大面积推，你懂得。5）有很多文本对比工具可以使用，做维护必不可少的工具 。6）做功能，要尽可能减少联动出发，能不用主从表就不要用主从表，能拆成单表就拆成单表，能用弹窗就不要在一个表单上维护两张表等等，总之，功能越单一，越不容易引入问题，越容易维护。

6、改bug会改得窝火难受，甚至夜不能寐，请多喝水，放宽心。

先写这么多吧。

祝所有暂时做维护的人员工作顺利，心情愉快。