3 条重要的软件开发原则

英文原文:3 Key Software Principles You Must Understand,翻译:iteye

在本文中将介绍 3 条重要的软件开发原则(DRY、KISS、YAGNI原则),你可能已经知道,也可能只知道其中一条。这些原则看似很简单,但实施起来会很难。无论如何,这些原则提供了一个管理复杂软件项目的强大的途径。当涉及到真实世界中的项目开发时,你会发现这些原则都是非常有用的。

原则1:不要重复自己(Don’t Repeat Yourself,DRY 原则)

这个原则非常重要,换言之,就是不要写重复的代码。

当你正在构建一个大型的软件项目时,你通常会被整体复杂性搞得不知所措。解决复杂性的最基本的策略是将系统分成若干个容易处理的部分。起初,你可能想将系统按组件划分,每个组件代表了一个子系统,其中包含了完成特定功能所需的一切。

组件还可以往下再分,这样复杂性将被降低到单一职责(single responsibility),每个职责可以使用一个类来实现,类包含了方法和属性。方法实现算法,这些算法和算法的子部分是构成软件业务逻辑的最小知识块。你只需要保证这些块不重复即可。

DRY 原则规定,在整个系统中,每一个小的知识块只可能发生一次,且每个知识块必须有一个单一、明确、权威的表征。

在一个完美的应用程序中,每一小块业务逻辑将被封装在一个表征中,也就是一个变量或一个类。变量被封装在一个能够被描述为一个职责表征的类中,类被封装在一个能被描述为功能表征的组件中。这种方式称为模块化架构,DRY 原则是其一个重要的部分。

实现 DRY

你可以按照以下方式降低软件项目的复杂度,以便更容易地发现潜在的重复问题:

●绘制软件架构图,并映射主要的组件,复杂的项目可能需要为每个组件绘制一个专门的架构图。

●如果你到达了连接职责的层级,你可能需要转换到 UML 图。

●在写代码块之前,根据它在项目中的层级命名。定义它代表什么,并确定你知道它在组件中的作用。

●定义表征应该展示的内容(如功能是在数据库驱动程序中执行 SQL)以及应该隐藏的内容(如数据库认证信息)。

●确保表征不依赖于另一个复杂层级的表征(如一个组件依赖于另一个组件中的类)。

当你发现正写的代码与之前写过的代码类似或相同,你就需要花时间来考虑你正在做什么,并确保不重复自己。

原则2:尽量简单、一目了然(Keep it Simple Stupid,KISS 原则)

最简单的解释往往是最正确的。

这里的 Stupid 翻译为“一目了然”更好一些,简单并不意味着一目了然,比如“.(){..&};.”,够简单吧,但看懂这是什么吗?这其实是一个 bash 中的 fork 炸弹(不断 fork 一个新进程,耗尽系统资源)。

所以做到简单的同时,还要做到一目了然。你也可以这样理解,将一个软件做得连白痴都会用。这就是用户体验的最高境界了。

如何做到简单且一目了然呢?这要归结到软件开发的可维护性和可理解性。KISS 原则往往体现在需求设计阶段,当你考虑如何将客户的需求转变成一个可实现组件时,尝试确认以下部分:

●收益和努力比例不调的功能

●高度依赖其他功能的功能

●可能会变得复杂的功能

总而言之,如果一个任务看起来超复杂,试着去考虑一种创造性、独特的方式。多花时间去讨论关键点,看是否有其他更合适的方案。

原则3:适可而止(You Ain’t Gonna Need It,YAGNI 原则)

YAGNI 原则指的是只需要将应用程序必需的功能包含进来,而不要试图添加任何其他你认为可能需要的功能。

在一个软件项目中,往往 80% 的时间花费在 20% 的功能上。

当你准备列出一个项目清单时,试着考虑以下问题:

●通过降低抽象的层级,来实现低复杂度

●根据特性将功能独立出来

●适度接受非功能性需求

●识别耗时的任务,并摆脱它们

这些原则看似简单,但在实际运作中,会有各种各样的问题出现。一旦你强迫自己应用这些原则,你会发现你距离创造一个完美的软件已经不远了。

时间: 2024-10-01 17:22:31

3 条重要的软件开发原则的相关文章

3 条你必须知道的软件开发原则

在本文中将介绍3条重要的软件开发原则,你可能已经知道,也可能只知道其中一条.这些原则看似很简单,但实施起来会很难.无论如何,这些原则提供了一个管理复杂软件项目的强大的途径.当涉及到真实世界中的项目开发时,你会发现这些原则都是非常有用的. 原则1:不要重复自己(Don’t Repeat Yourself,DRY原则) 这个原则非常重要,换言之,就是不要写重复的代码. 当你正在构建一个大型的软件项目时,你通常会被整体复杂性搞得不知所措.解决复杂性的最基本的策略是将系统分成若干个容易处理的部分.起初,

敏捷软件开发:原则、模式与实践(笔记)

一.敏捷软件开发宣言 1.个体和交互 > 过程与工具 a)人是获得成功最为重要的因素: b)合作.沟通以及交互能力要比单纯的编程能力更为重要: c)团队的构建要比环境的构建重要. 2.可以工作的软件 > 面面俱到的文档 a)文档应该短小并突出主题: b)在给新的团队成员传授知识方面,最好的两份文档是代码和团队: c)直到迫切需要并且意义重大时,才来编制文档. 3.客户合作 > 合同谈判 a)成功的项目需要有序.频繁的客户反馈. 4.响应变化 > 遵循计划 a)构建计划时,应该确保计

敏捷软件开发原则

敏捷软件开发原则 ----<敏捷软件开发原则.模式与实践>学习笔记 最近在系统地学习并且有意地在工作中实践敏捷软件开发,文章乍看起来,都是一些说教性.理论性,比较无聊的东西. 但是如果静下心来结合自己自身的经历.思考地去阅读,可能会发现,有的观点确实很赞同,然而有的可能会有自己的想法. 以下是在<敏捷软件开发 原则.模式与实践>一些读书笔记,斜体字是直接摘录于书本,非斜体字是自己的一些理解.   一.尽早的,持续地交互有价值的软件来使客户满意.初期交付的系统功能越少,最终交付的系统

一些软件软件开发原则

下面这些原则,不单单只是软件开发,可以推广到其它生产活动中,甚至我们的生活中. Don't Repeat Yourself (DRY) DRY 是一个最简单的法则,也是最容易被理解的.但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事).它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法. 参考:http://en.wikipe

[书摘]《敏捷软件开发: 原则、模式与实践》第一部分:敏捷开发

面向对象设计的原则 单一职责 开放-封闭 Liskov替换原则 依赖倒置原则 接口隔离原则 重用发布等价原则 共同封闭原则 共同重用原则 无环依赖原则 稳定以来原则 稳定抽象原则 人的重要性 交付产品的关键因素是人,而不是过程.(敏捷 Agile) 人与人之间的交互式复杂的,并且其效果从来都是难以预期,但却是工作中最为重要的方面. ------ Tom DeMacro 和 Timothy Lister<人件> 有凝聚力的团队将具有最强大的软件开发力量. 敏捷软件开发宣言 我们一直在实践中探寻更

读书笔记-敏捷软件开发 原则,模式与实践

看了一下夹在书中的发票,2010年在当当网购买的. 断断续续的也看过几次,一直没有看完过. 这次试着写写读书笔记.看看能不能坚持住.

敏捷软件开发 – OCP 开放-封闭原则

软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改的. 如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就具有僵化性的臭味.OCP建议我们应该对系统进行重构,这样以后对系统再进行这样那样的改动时,就不会导致更多的修改.如果正确地应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码. OCP概述 遵循开放-封闭原则设计出的模块具有两个主要的特征.它们是: 对于扩展是开放的(open for extension).这意味着模块的行

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何

敏捷软件开发 – ISP 接口隔离原则

如果类的接口不是内聚的,就表示该类具有“胖”接口.换句话说,类的“胖”接口可以分解成多组方法.每一组方法服务于一组不同的客户程序. ISP承认有一些对象确实需要有非内聚的接口,但是ISP建议客户程序不应该看到它们作为单一的类存在.相反,客户程序看到的应该是多个具有内聚接口的抽象基类. 接口污染 考虑一个安全系统.在这个系统中,有一些Door对象,可以被加锁和解锁,并且Door对象知道自己是开着还是关着.这个Door编码成一个接口,这样客户程序就可以使用那些符合Door接口的对象,而不需要依赖于D