关于代码重复最著名的单词是Kent Beck的Once And Only Once,也就是说软件操作的任何一个片断--不管是一个算法,一个常量集合,用于阅读的文档或者其他东西--应当只出现一次。
软件重复出现至少会导致以下问题:
- 其中的一个版本会过期
- 代码的责任会四处散开,导致代码难以理解
- 当你修改代码时,需要重复修改很多地方,一不小心就会遗漏
- 你不能很好地进行性能优化
我们可以来看看DavidHooker提出的7个软件开发原则:
第一原则: 存在的理由(Pattern: TheReason)一个软件系统存在的理由就是:为它的用户提供价值。
你所有的决定都取决于这一点。在指定一个系统需求,在写下一段系统功能,在决定硬件平台和开发过程之前,问你自己一个问题,“这样做会为系统增加价值吗?“,如果答案是”yes”,做。如果是”No”,不做。这个原则是其他原则的原则。
第二原则 KISS (Pattern: KeepItSimple) 软件设计不是一个轻描淡写的过程。
在做任何一个设计时,你必须考虑很多因素。所有设计应当尽可能简单,但是不要再比这简单了。这样产生的系统才是可以理解和容易维护的。这并不是说很多由意义的特性,因为这种简单性也要被抛弃。确实很多更优雅的设计往往更简单,但简单并不意味着“quick and dirty."。事实上,简单是通过许多思考和一次一次的反复修改才达到的。这些努力的汇报就是更容易维护,代码错误更少。 (看看是否违反)
第三原则 : 保持远见(Pattern: MaintainTheVision) 清晰的远见是一个软件项目成功的基础。
没有这样的远见,项目开发最后就变成天天为一个不好的设计做补丁。Brooks说过: 概念的完整性是系统设计中最重要的问题。 Stroustrup 也说: 有一个干净的内部结构识构建一个可理解、可辨识、可维护 、可测试系统的基础。 Booch则总结道: 只有当你对系统的体系由一个清晰的感觉,才可能去发现通用的抽象和机制。开发这种通用性最终导致系统更简单,因此更小,更可靠 如果你不断地复制、粘贴、修改代码,最终你将陷入一个大泥潭(the Big Mud),你永远不可能对系统有一个清晰的认识。
第四原则: 你制造的,别人会消费 (Pattern: WhatYouProduceTheyConsume) 软件系统不是在真空中使用的。
其他人会使用、维护、文档你的系统。这依赖于对你系统的理解。所以,你设计、实现的东西应当能够让别人理解。要记住,你写的代码并非只给计算机看,你要时时记住,代码还要给人看。(Kent Beck) 如果到处泛滥似是而非的代码,别人如何能够辨别这些代码的相似和不同,如何去理解这些代码之间具有何种关系。
第五原则: 对将来开放( Pattern BuildForTodayDesignForTomorrow) 一个成功的软件有很长的生命期。
你必须能够使得软件能够适应这样和那样的变化。所以,一开始就不要软件设计到死角上去。请总是问一下自己“如果这样,那么。。?“这个问题,你要考虑到各种各样的可能性,而不光光是图省事。复制,粘贴一下即可。
第六原则:为重用做好计划
软件模式是重用计划的一种。不断重复的代码显然不是这样的计划。 (See CommentsOnSix)
第七原则: 思考!
在采取任何动作之前首先做一个清晰、完整的考虑,这样才能产生更好的结果。如果你考虑了,但还是产生错误的结果,那么这种努力也是值得的。在你学习或研究类似的问题时,更容易理解和掌握。
这些原则告诉我们轻松地复制、粘贴和修改代码不可能产生好的,也就是容易理解、维护、重用的代码。但请不要走极端。 我一直认为,一个好的软件系统是各种因素权衡的结果,也就是你如何把握一个度的问题。重复代码产生的另外一个主要原因就是做得太多,XP有一个基本原则叫做You Arent Gonna Need It,它是说“只实现你真正需要的东西,从来不去实现你预期需要的东西“。如果你去实现你现在认为将来需要的东西,不一定就是你以后真正需要的东西。你处于现在的环境中可能无法理解你要实现东西究竟是什么样子的。你会浪费大量的时间去构造这样不知道是否必须的可能性。同时,当你真正实现的时候就可能产生重复代码。
Martin Fowler在它的Refactoring一书中有很多用来处理代码重复,包括:
1.同一个类的两个方法中有相同的表达式,使用Extract method,然后大家都调用该method;
2.两个兄弟子类之间有相同的表达式,那么在这两个子类中使用Extract Method,接着使用pull up field,移到共同的超类
3.如果结构相似而并非完全相同,用Extract method把相同部分和不同部分分开。然后使用Form Template method.
4.如果方法使用不同的算法做相同的事情,那么使用substitute algorithm
5.如果在两个不相干的类中有重复代码,那么在一个类中使用Extract class,然后在其他类中使用该class对象作为元素等等。
分享到:
相关推荐
### 软件开发的201个原则 #### 一、概述 《软件开发的201个原则》是一本全面阐述软件开发过程中应当遵循的原则性指导书籍。该书内容丰富,覆盖了从项目启动到交付的各个阶段,旨在帮助软件开发团队提高产品质量、...
《软件开发的201个原则》是一本为程序员、项目经理以及任何参与软件开发过程的人提供指导的宝贵资源。这本书涵盖了从设计到实现、测试到维护的全过程,帮助读者理解和应用这些原则来提升他们的专业能力。 1. **敏捷...
在软件开发过程中,设计原则是指导开发者构建高效、可维护和扩展软件系统的重要准则。这些原则不仅提高了代码质量,还能确保团队之间的沟通清晰,降低维护成本。以下将详细阐述一些核心的软件开发设计原则。 1. **...
《敏捷软件开发:原则、模式与实践》是Robert C. Martin(简称Uncle Bob)的一部经典著作,这本书深入探讨了敏捷开发的理念、方法和工具,尤其针对C#编程语言进行了详细阐述。作为一本实践导向的技术书籍,它旨在...
《敏捷软件开发:原则、模式与实践》是一本深度探讨敏捷开发理念、方法和技术的权威著作。这本书由著名软件开发专家Robert C. Martin撰写,旨在帮助开发者和团队更有效地进行软件开发,提升软件项目的成功率。书中...
《敏捷软件开发:原则、模式与实践》是一本深度探讨敏捷开发理念和技术的权威著作,由业界知名专家Robert C. Martin(简称Uncle Bob)撰写。这本书不仅提供了丰富的理论知识,还结合实际案例,深入浅出地介绍了如何...
敏捷软件开发原则、模式和实践涉及的几个关键方面如下: 1. 敏捷宣言的核心价值: 敏捷宣言是由一群软件开发人员起草的一份文档,其核心价值体现了敏捷开发的核心理念,包括: - 个体和互动高于流程和工具 - 可...
技术设计原则是软件开发的基本原则,包括规范性原则、可靠性原则、扩展性原则、开放性原则、易用性原则、安全保密原则等。这些原则是软件开发的核心要求,决定着软件项目的质量和可靠性。 2.3 可靠性原则 可靠性...
7. 软件开发的基本原则:软件开发的基本原则是软件开发的核心要素之一。它包括避免混乱低效的开发、避免典型错误、打好开发基础、管理风险和采取面向进度的实践等几个方面。 软件开发的基本原则是软件开发项目的...
软件开发要遵循的七大原则
中文名: 敏捷软件开发:原则、模式与实践 原名: Agile Software Development:Principles,Patterns and Practices 别名: 软件工程实践丛书 作者: (美)Robert C.Martin译者: 邓辉 孟岩图书分类: 软件 资源格式: PDF ...
《敏捷软件开发:原则、模式与实践》是敏捷开发领域的一部经典著作,全面而深入地探讨了敏捷方法的核心理念、关键原则、实用模式以及实践经验。这本书由Robert C. Martin撰写,他是一位知名的软件工程师和敏捷开发的...
7. 软件开发计划书的缺点: 软件开发计划书的缺点是需要投入一定的人力和物力,编写和实施需要一定的时间和资源。 8. 软件开发计划书的应用场景: 软件开发计划书的应用场景非常广泛,涵盖了软件开发的整个过程,从...
敏捷软件开发:原则、模式与实践 Bob大叔经典力作,历时7年
敏捷开发-敏捷软件开发:原则、模式与实践(全).pdf
基于构件的软件开发技术 本文以某公司生产经营管理系统为例,探讨了基于构件的软件开发问题。该系统是一个集原料采购、生产管理、物流管控...7. 基于构件的软件开发技术在软件开发中的应用(某公司生产经营管理系统)
《敏捷软件开发:原则、模式与实践》是一本深度探讨敏捷开发理念和技术的权威书籍,中文高清版使得读者能够更加清晰地理解其中的精髓。这本书是提升编程技能和项目管理能力的重要参考资料,对于IT行业的从业者来说,...
第Ⅰ部分 敏捷开发 第一章 敏捷实践 1.1 敏捷联盟 1.2 原则 1.3 结论 参考文献 第二章 极限编程概述 2.1 极限编程实践 2.2 结论 参考文献 第三章 计划 3.1 初始探索 3.2 发布计划 3.3 迭代计划 3.4 任务计划 3.5 ...