可维护性（maintainability）——回到现场

     今天说说可维护性，一般来说80%的代码都不是本人进行维护的。

 

     影响可维护性的因素：

 

     1）是否是同一个开发人员。

     2）是否有一个很好的code base。

     3）是否有完善的文档，文档是否同步。

     4）代码是否有注释。

     5）维护人员对业务领域是否了解。

 

     软件维护主要工作：

 

     1）修正缺陷。

      如果不了解业务，首先要了解业务。分析缺陷产生的原因，找到应该修改的模块。了解类直接的关系。修正缺陷，测试。

 

      2）满足新的需求

      如果不了解业务，首先应该了解业务。然后分析新需求和系统的功能对比。设计如何增加新功能，分析如何接口老的功能。进行重构，编写测试。 

 

     3）重构，为了使以后代码更容易维护。

      了解新老业务需求，绘制域模型，绘制整体流程图，找出系统涉及的角色，了解系统和其它外部系统的接口。  

 

     为了防止人的因素影响可维护性，要保证每一块业务始终有一个人熟悉。

     关键部分，比如需求，架构设计，数据库设计，域模型，流程图最好文档化下来，并保持更新。

     每次修改，应该记录修改人，修改时间，修改内容。应该文档化每次修改活动的细节。

 

     其实，维护软件最头痛的是，随着时间的流逝，以前的关于系统的理解和记忆已经逐渐消失了。每次修改bug或增加新功能，要通过看文档，看代码来回忆当时开发系统时的场景。最终目的是使维护人员的头脑能够恢复到开发时的上下文。

     可惜人脑不能录像，否则把当时人脑思考的过程记录下来。那么，是否可以记录一些当时的场景呢？

 

     比如对关键讨论录像保存，用数码相机拍下白板上的讨论结果，以模块为主题组织这些资料，定期的更新它。除了我们写就的文档，这些片段其实都可以保存下来。 像文物和考古学家一样，我们在维护一个老系统，也是在考古，任何以前的蛛丝马迹都可能启发我们，使我们找回当时我们的上下文。

 

     还有一个就是单元测试，非常重要，它像考古学家使用的探针。当时光荏苒，日月如梭，转眼到了几年后。只要你不色盲，你仍然可以凭借红条和绿条来唤起你的回忆。

 

     养成随时记录的好习惯，可以参考我的这篇文章程序员的结构化思维方法——一个思维脑图模板 ， 使用这样的模板，你可以随时记录你的思考过程，相当于把它序列化下来，我觉得非常有用。

 

     对于一些常规的任务，比如部署注意事项（可能会修改配置文件，拷贝一些类），把这些整理成checklist，到时候不用动脑子，直接照着做就行了。

 

     可扩展性是可维护性的技术基础。清晰的代码和文档也非常重要，换句话说，可理解性是可维护性的前提。如果你都不理解它，你怎么维护它呢。

 

     下一篇文章，我说说可理解性，这个我认为是软件开发中的最重要的属性。

 

 

修改日志：

 

2009-02-12 ： 增加单元测试，养成好的记录习惯以及checklist使用建议三点。