程序维护的时候经常遇到两个困难:
1、不知道这段代码是实现什么功能的(code —— function);
2、不知道这个功能是实现什么需求的(function —— business)。
解决第一个问题是比较容易的,大家都是搞技术的,一头扎进代码里去,看上几十分钟,通常就能明白:原来这段代码是从数据库里面找到前三个月一直处于停机状态的号码,然后把这些号码放到一个叫做QUIT_USER的数据表里面去。
第二个问题就难了,经常从代码中是看不出来的,于是项目开发的过程中就制造出来了大量的文档,来帮助开发者交流这个问题,也让将来维护这段代码的人知道这个知识。
我们可以查找与这段代码相关的文档,文档上说:这段代码把停机三个月的号码放到一个叫做QUIT_USER的表里面,一个月以后,这些号码由另外一段代码拿去筛一下,把最近刚交了费用的号码删掉,剩下的用户做退网,号码回收,冻结半年以后可以重新使用。
令人难过的是,维护程序的人很难有幸看到如此贴心的文档。他们查了半天经常看到的是:这段代码按照xxx的规则,从xxx表中查询数据,然后再把结果的数据经过xxx的处理,放到QUIT_USER表里面,over。你仍然不知道他到底是在做什么。
并且,文档与代码的同步也是一个难题。不仅是文档,即使是代码中的注释,谁又能保证他真实的描述了系统的运行方式呢?时间紧张、错误的理解都可能造成文档与实际情况不同。我们假定写文档和写注释的人是认真的、不犯错误的,他们也必须忽略一些细节,他们不能什么都写上去。而他们忽略的细节很有可能为以后的维护带来麻烦。
很多项目都有这个问题:business和function是脱节的。熟悉客户业务的人设计出一系列的功能点,这些功能点按照最初的设计是可以完成客户的业务的。然后这些功能点就拿到开发人员那里去造出来。而开发人员对用户的business其实是不了解的,他们的眼中只有function。到了维护的时候,business发生了变化,function重新设计。经常是经过一番修改,程序按照开发人员的思路运行良好,但是用户却一个劲的摇头:“不不,不是这样的,我们要的是这个……”程序到底解决了哪些business,已经成了一个迷。
什么东西可以最准确的描述程序的运行过程呢?只有代码本身。并且,经过精心设计的代码也能很好的对business进行描述。比如刚才说的那件事情,一段代码把号码放到QUIT_USER里面,另一段代码从这里面筛除一些号码做退网。这两个function其实在business方面都属于一个点,那么就应该让这两段代码写在一起,封装起来——这就是高内聚。并且这一段代码内部的操作应该与其他的功能没有任何关系,除非那个功能与这两个功能具有business上的共同点,别的代码应该不知道QUIT_USER是个什么东西——这就是低耦合。
一个项目的代码,总是由大尺度的构思开始的,然后越来越贴近细节,牵涉越来越多的技术。但是写到最后,代码应该回到对business本身的描述。代码越贴近business,对维护的帮助就越大。
我现在要维护一个公司的财务管理程序,我想知道职员的工资里面是不是已经计入了他们的个人所得税。我找到Account(会计),他应该有一个方法,每个月运行一次,把Salery发给Emplyee,我找到这个Salery,看到里面已经包含了Tax。我发现Account计算这个Tax的时候使用了一个Stratagy(策略)。他调用的是一个名叫Stratagy1998的策略,以800元作为基数计算个人所得税。现在这个基数已经发生了变化,于是我修改这个Stratagy1998、或者替换掉一个新的Stratagy2005。这样就完成了一次变更。并且我知道这样修改不可能影响到business不相关的东西。
文档永远只能表示“某时某刻我们曾经这样想过”,让文档时刻保持与代码的同步是不实际的。要想知道“现在程序是怎样运行的”,只有代码能够告诉我们。文档应该配合代码,做代码不能做的事情,配合把business说清楚。而不应该与代码发生冲突。
文档应该去描述代码无法说清楚的事情上,比如用户的工作场景、某个需求是由谁提出来的、大尺度的程序设计、重要对象的运行时序、系统安装手册。比如下面这个图,他清楚的说明了“销户”这个行为在整体的需求中处于什么地位。这样的东西用代码说清楚是比较费力的。当然用代码也能说清楚,比如可以使用State - Action模式,但是总归不如一张图表示的这么清楚。
XP和Agile方法所提倡的“尽量少写文档”,就是基于这样一种设计理念:尽量的用代码和测试代码来描述business,以达到知识的交流和维护的便利。代码是最重要的沟通语言。在代码说不清楚的情况下,文档也是必须的。
分享到:
相关推荐
9. **维护与升级计划**:规划软件的长期维护和支持,包括版本控制、错误修复、新功能添加和性能优化。 10. **项目管理计划**:包括项目的范围、时间、成本、质量、人力资源、沟通、风险等方面的管理策略,确保项目...
软件维护面临的问题主要包括:理解原有代码的困难,尤其是在缺乏文档或文档不准确的情况下;原始开发人员可能不再参与维护工作,导致解释软件的困难;很多软件在设计时并未考虑未来修改的需求;以及维护工作本身的...
"软件模板——国标"是一套基于中国国家标准的专业文档模板集合,旨在为软件工程文档的撰写提供规范和指导。这些模板涵盖了软件生命周期中的各个阶段,包括需求分析、设计、编码、测试以及维护等,确保了文档的一致性...
7. **维护手册**:包含了软件的更新、修改和故障排查指南,为后期的软件维护工作提供参考。 8. **项目进度报告**:跟踪和记录项目的进度,包括任务分配、里程碑完成情况、时间延误分析等,以便于项目管理。 9. **...
软件维护面临的主要问题包括理解他人编写的代码困难,特别是缺乏足够的软件配置文档,或者已有的文档不准确或过时。此外,原始开发团队可能无法参与维护工作,使得接手的维护人员需要花费更多时间和精力去理解和更新...
4. **详细设计文档**:这份文档深入到每个模块的具体实现,包括类图、用例图、序列图等UML图,以及伪代码或算法描述,帮助开发者理解和实现代码。 5. **编程标准与规范**:定义了代码编写的基本规则,如命名规范、...
使用国家标准软件开发文档模板GB856T——88.aibxyz,你可以按照这些结构来组织你的文档,确保它们符合国家规定的标准,有利于团队间的沟通和项目的顺利进行。每个部分都应详细、准确地填写,以保证所有项目参与者都...
9. **软件文档**:编写和维护必要的技术文档,如用户手册、开发者指南和系统文档,以促进团队间的沟通和理解。 10. **团队协作与沟通**:在软件开发中,有效的团队合作和沟通对于项目的成功至关重要。 实践部分...
《国标软件设计文档GB8567——88》是中国在1988年制定的一项国家标准,旨在规范软件开发过程中的文档编制工作,提高软件质量和开发效率。这份标准详细规定了软件设计文档的结构、内容和编写要求,是软件工程领域的...
下面将对标题“常用软件术语——软件工程”所涉及的核心概念进行深入解析,旨在为读者提供一个全面而细致的软件工程词汇表,帮助大家更好地理解和应用这些术语。 ### 软件工程 软件工程是一门研究如何系统化、规范...
在软件开发过程中,技术文档是不可或缺的一部分,它不仅有助于团队成员之间的沟通,还能确保项目的顺利进行和后期维护。本教程“软件开发技能实训教程——技术文档篇”将带你跟随Microsoft工程师的脚步,深入学习...
在实际工作中,遵循GB8567——88标准编写软件设计文档,能够有效地提升软件开发的效率和质量,降低维护成本,是软件工程师必备的专业技能。通过这份《标准软件设计文档(GB8567——88)》模板,开发者可以快速上手,...
此外,还强调了文档在整个软件生命周期中的关键作用,良好的文档能有效支持后期的维护和扩展。 总的来说,《软件工程——实践者的研究方法》是一本全面介绍软件工程实践的指南,它不仅包含了丰富的理论知识,更注重...
在软件开发过程中,软件需求分析是至关重要的第一步,它为后续的设计、编码、测试和维护提供了清晰的方向。这个名为“软件工程——软件需求分析课件”的压缩包包含了多个关于需求分析的课程材料,旨在深入探讨这一...