原文地址：
引言：
我阅读过大量关于开发方面的书籍和文章，包括设计、架构、编码以及项目计划和项目管理，但很少有关于卑微的软件维护工作的。在软件生命周期的研究中倒是经常会提到维护，但印象中真正的设计和编码技术通常都是通过开发过程来讲授的，而不是维护过程。
什么是软件维护？我在这里不想给它下定义，也不想引用别人的定义，只是想把维护阶段的软件和开发阶段的软件做一对比，得出维护阶段软件的下列特征：
- 初始的开发者已经离开了公司或者转到了其他项目。与开发软件时相比，维护软件的人要少得多。
- 对维护阶段软件的期望通常会比较低，维护工作主要包括修正一些用户提出的bug、添加一些新功能。但这些功能不会作为软件的“旗舰”功能。
- 代码维护经常会使用一些过时的甚至不再支持的技术，代码的质量通常会因为频繁的bug修正和随意删改而变的很糟糕。
良好的软件维护实践：
这里我提供的几条是我工作中的切身体会。你可能会发现它们并不适用于你，更有可能的是一部分适用而一部分不适用。如果你有任何好的建议，可以写在文章下面的留言里。
1． 试着去喜欢软件维护工作
一个人怎么才能喜欢软件维护工作呢？开发者通常都梦想成为他们团队的首席架构师，要求他们维护已有的软件对他们来说简直就是惩罚。其实完全不必这样。软件维护工作同样存在大量的挑战，同样需要创造性、灵活性、耐心、训练和良好的沟通。它对你而言也是一次不错的职业经历：在你的简历中有一条夸张的“构架了n层24/7的企业应用程序”的确看上去不错，但雇主通常更看重能够解决问题的人，而软件维护工作为你提供了一个展现你解决问题能力的机会。
2． 熟悉所维护软件的功能
熟悉所维护软件的功能是非常重要的。阅读现有的文档，而且一定要对文档中提到的内容亲自进行测试。如果你们有一个QA部门，试着找出他们的测试计划文档，并且照着文档再把测试做一遍。掌握现实中软件的使用方法，确保你要知道最常用的使用情形。有时候用户会要求提供一些已经存在的功能特性，只是因为他们不知道软件中已经具有了这些功能。其它的时候，可能就需要我们动手调试程序了。如果你是所维护系统的一个超级用户，就可能会用最少的时间来完成调试。
3． 熟悉所维护软件的体系结构
你会希望得到详尽的、最新的设计文档，包括需求、功能规范、高级设计和底层设计，还要有注释良好的代码，对不对？而实际上，这种情形出现的可能性几乎为零。更有可能的是你得到一点点文档（如果有的话），还有可能是过期的。代码——或者是部分代码——是有注释的，但你不能确信这些注释是不是最新的。如果代码中途被人修改过而相应的注释没有随之更新，这样的注释反而具有更大欺骗性。
研究你的代码，试着去理解各种类、模块和组件在软件中所扮演的角色。使用调试器单步执行不同的使用情形，查看当代码的不同部分执行时将会发生什么。一定要记下你的发现并以某种方式把他们组织起来。你可以记录成非常正式的uml图形，也可以是易于理解的其它方式。要把熟悉软件的体系结构当作一个持续进行的过程，而不是一件一次就能完成的事情。当你修正bug或添加新的特性时，可能会对系统有更好的理解，这时也一定要记下你的发现。
4． 与客户沟通
与客户沟通是非常重要的。许多软件开发者都很内向，他们宁愿与技术打交道，也不愿意去与客户沟通。然而，软件就是为了人们使用才开发的。而且在软件的维护阶段，已经有客户在使用我们的软件了。了解客户怎么使用软件、为什么要这么适用、他们想要解决什么问题和他们需要什么样的功能是非常重要的。而要了解这些问题，就不能等着他们来找你，而是要主动去找他们。试着建立一种简单而有效的机制用于客户提交bug报告和增加需求。当他们提出一个问题时，要及时给他们反馈——即使你不能马上解决这个问题——至少让他们知道你正在处理这个问题，而没有怠慢他们。最后，要诚实的告诉他们问题的最新解决情况，如果由于某些原因不能满足他们的需求，也要及时告诉他们。
5． 如果有可能，与最初的开发者沟通
如果你够幸运，你会发现一些最初的开发者还留在公司里。当然，他们可能已经高升而且不愿意再去碰那些你正在维护的乱七八糟的旧软件了。但是他们的确能给你提供很大的帮助，从而节省你大量的时间。不要指望他们会给你修改代码，只需要他们告诉你该怎么做，或者给你解释一下有些部分的工作原理，或者给你提供一些有帮助的提示就足够了。再次说明，同他们打交道也需要很多人际交往技巧，很多开发者都缺乏这些技巧，但我们可以慢慢的去学。
6． 保留修改记录
有很多种保留修改记录的方法。最常见的方式是在每次提交代码前要进行注释说明（我确信你一定使用了源代码控制系统），还有些人喜欢把修改的记录列表写到文件的顶部，在电子表格中保留一份修改列表也是很方便的。无论你采用哪种方式，一定要重视它。一份精确的修改记录对成功地维护工作来说是无价的——即使以前的人都不关心或者你只有一部分修改记录。
7． 保持保守
在软件维护的很多时候，你会被某些模块中的代码整的很沮丧。真想把这些代码删除然后从头重写。在你真的要重写之前，先问问你自己下面几个问题：
- 重写对你的公司和客户能够带来什么好处？丑陋的代码，或者说在你看来丑陋的代码本质上不能作为重写的一个理由。用户要添加一个新功能而在当前的代码上无法实现倒是可以作为一个重写的理由。
- 你确信你明白这段代码是干什么用的，是如何运行的？
- 你确信你知道这段代码怎样与系统的其它部分通信么？知道哪些模块和功能要依赖于这段你要重写的代码么？
- 你确信你能使它更好么？也许你会陷入与初始开发者遇到的同样的麻烦中。情况可能不会发生改变，甚至变糟。
事实上，无论何时我们对代码进行修改，不管是多么微小的修改，都存在引入新的bug的风险。因此，我们对当前的情形要尽可能的保守一些。当用户有新的要求时，我们要尽可能的在一个独立的模块里来实现而不修改原有代码。只要软件还能运行就不要去修改它。如果软件出问题了，就要对它进行修补而不是从头重写。使修改所造成的影响越小越好——你也不想改善了系统的一部分而使其它部分崩溃吧。
避免重构。尽管在开发阶段重构是一项很有用的技术，但在软件的维护阶段，它可能只会给你带来麻烦。即使你使用重构没有破坏任何东西，至少也增加了维护记录的复杂度，使源代码管理系统中不同版本间的差别变大（我想你一定使用了源代码控制系统，对不对？）。
同时，当你确定需要修改代码或者添加新功能后，就马上按正确的方法去做。我经常听到大家说，“马上就要到期了，我们先随意删改糊弄一下，以后我们可以再好好的重写”。然而，由于种种原因，“以后”往往意味着“永远都不”。所以，如果你要做，就马上好好的去做；如果不想做，就坦白的讲不要做，而不要拿“以后”做借口。
8． 每次修改后进行测试
当你接手软件的维护工作时，也许你需要做的第一件编码任务是为该软件写一份回归测试集——除非你已经有了一份，不过一般而言，你不会那么走运。的确，自动测试不能保证代码中没有一点bug，但这不应该作为不使用自动测试的借口。不能暴露所有的bug，但至少可以帮你发现一部分bug，同时可以使你确信你对软件的修改并没有破坏它的核心功能。一个不错的做法是对你得到的每一份检测报告，都写一个测试用例来重新生成一次，这样你就可以知道当你修改其它部分时有没有再引入bug。
有时，你可能只是对代码做了一点修改，并要把它提交到源代码控制系统中（你确实使用了源代码控制系统，对不对？）。但是运行整个的回归测试却会花费很长的时间。这种情况下，我们可以取出回归测试集的一个子集进行一次“冒烟测试”——只覆盖了回归测试集中的一部分测试用例的测试。每次修改后你都可以进行“冒烟测试”，而在周末或晚上进行回归测试。
9． 即使不喜欢，也要接受代码中的编码规范
编码规范有些个人信仰的因素在里面。而且一般而言，要使一个人从根本上改变使用哪种编码规范是很困难的。即使有些语言 (如java、vb或c#)的发明者建议了一些基本的编程规范，开发者还是对它争论不休。而对于那些发明者要开发者自己决定编码规范的语言(c，c++,perl)，选用哪种规范的争论简直就是一场战争。
我知道我不能说服大家使用哪种编码规范，但请试着使用你维护的软件的编码规范吧。即使在整个系统中没有统一的编码规范，那至少在模块的层次上的编码规范应该是统一的，因为一般情况下都是一个人负责开发一个模块。最坏情况下，一些初始开发者之外的人已经修改过了代码并且引入了新的编码规范，所以你必须面对一堆可怕的混合在一起的编码规范。这时，你需要从这些规范中选择一种作为你维护的编码规范，而不要再引入新的编码规范了。
结论：
软件维护工作有它独特的挑战性，迎接这些挑战同样需要技巧和方法，与开发工作是一样的。在这篇文章里，我列举了在我的工作中发现的一些比较好的做法，绝不能真的做为软件维护艺术。
阅读(2204) | 评论(0) | 转发(0) |
