软件维护之经验谈.pdfVIP

软件维护之经验谈 一、 引 言 我阅读过大量关于开发方面的书籍和文章，包括设计、架构、编码以及项目计划和项目 管理，但很少有关于卑微的软件维护工作的。在软件生命周期的研究中倒是经常会提到维护， 但印象中真正的设计和编码技术通常都是通过开发过程来讲授的，而不是维护过程。 什么是软件维护？我在这里不想给它下定义，也不想引用别人的定义，只是想把维护阶 段的软件和开发阶段的软件做一对比，得出维护阶段软件的下列特征： ·已经部署完成而且投入使用。 ·初始的开发者已经离开了公司或者转到了其他项目。与开发软件时相比，维护软件的人 要少得多。 ·对维护阶段软件的期望通常会比较低，维护工作主要包括修正一些用户提出的、添加一 些新功能。但这些功能不会作为软件的“旗舰”功能。 ·代码维护经常会使用一些过时的甚至不再支持的技术，代码的质量通常会因为频繁的修 正和随意删改而变的很糟糕。 二、良好的软件维护实践 这里我提供的几条是我工作中的切身体会。你可能会发现它们并不适用于你，更有可能 的是一部分适用而一部分不适用。如果你有任何好的建议，可以写在文章下面的留言里。 ． 试着去喜欢软件维护工作 一个人怎么才能喜欢软件维护工作呢？开发者通常都梦想成为他们团队的首席架构师， 要求他们维护已有的软件对他们来说简直就是惩罚。其实完全不必这样。软件维护工作同样 存在大量的挑战，同样需要创造性、灵活性、耐心、训练和良好的沟通。它对你而言也是一 次不错的职业经历：在你的简历中有一条夸张的 “构架了层的企业应用程序”的确看上去不 错，但雇主通常更看重能够解决问题的人，而软件维护工作为你提供了一个展现你解决问题 能力的机会。 ． 熟悉所维护软件的功能 熟悉所维护软件的功能是非常重要的。阅读现有的文档，而且一定要对文档中提到的内 容亲自进行测试。如果你们有一个部门，试着找出他们的测试计划文档，并且照着文档再把 测试做一遍。掌握现实中软件的使用方法，确保你要知道最常用的使用情形。有时候用户会 要求提供一些已经存在的功能特性，只是因为他们不知道软件中已经具有了这些功能。其它 的时候，可能就需要我们动手调试程序了。如果你是所维护系统的一个超级用户，就可能会 用最少的时间来完成调试。 ． 熟悉所维护软件的体系结构 你会希望得到详尽的、最新的设计文档，包括需求、功能规范、高级设计和底层设计， 还要有注释良好的代码，对不对？而实际上，这种情形出现的可能性几乎为零。更有可能的 是你得到一点点文档（如果有的话），还有可能是过期的。代码——或者是部分代码——是 有注释的，但你不能确信这些注释是不是最新的。如果代码中途被人修改过而相应的注释没 有随之更新，这样的注释反而具有更大欺骗性。 研究你的代码，试着去理解各种类、模块和组件在软件中所扮演的角色。使用调试器单 步执行不同的使用情形，查看当代码的不同部分执行时将会发生什么。一定要记下你的发现 并以某种方式把他们组织起来。你可以记录成非常正式的图形，也可以是易于理解的其它方 式。要把熟悉软件的体系结构当作一个持续进行的过程，而不是一件一次就能完成的事情。 当你修正或添加新的特性时，可能会对系统有更好的理解，这时也一定要记下你的发现。 ． 与客户沟通 与客户沟通是非常重要的。许多软件开发者都很内向，他们宁愿与技术打交道，也不愿 1 / 3 意去与客户沟通。然而，软件就是为了人们使用才开发的。而且在软件的维护阶段，已经有 客户在使用我们的软件了。了解客户怎么使用软件、为什么要这么适用、他们想要解决什么 问题和他们需要什么样的功能是非常重要的。而要了解这些问题，就不能等着他们来找你， 而是要主动去找他们。试着建立一种简单而有效的机制用于客户提交报告和增加需求。当 们提出一个问题时，要及时给他们反馈——即使你不能马上解决这个问题——至少让他们知 道你正在处理这个问题，而没有怠慢他们。最后，要诚实的告诉他们问题的最新解决情况， 如果由于某些原因不能满足他们的需求，也要及时告诉他们。 ． 如果有可能，与最初的开发者沟通 如果你够幸运，你会发现一些最初的开发者还留在公司里。当然，他们可能已经高升而 且不愿意再去碰那些你正在维护的乱七八糟的旧软件了。但是他们的确能给你提供很大的帮 助，从而节省你大量的时间。不要指望他们会给你修改代码，只需要他们告诉你该怎么做， 或者给你解释一下有些部分的工作原理，或