在本文中将介绍3条重要的软件开发原则,你可能已经知道,也可能只知道其中一条。这些原则看似很简单,但实施起来会很难。无论如何,这些原则提供了一个管理复杂软件项目的强大的途径。当涉及到真实世界中的项目开发时,你会发现这些原则都是非常有用的。
原则1:不要重复自己(Don’t Repeat Yourself,DRY原则)
这个原则非常重要,换言之,就是不要写重复的代码。
当你正在构建一个大型的软件项目时,你通常会被整体复杂性搞得不知所措。解决复杂性的最基本的策略是将系统分成若干个容易处理的部分。起初,你可能想将系统按组件划分,每个组件代表了一个子系统,其中包含了完成特定功能所需的一切。
组件还可以往下再分,这样复杂性将被降低到单一职责(single responsibility),每个职责可以使用一个类来实现,类包含了方法和属性。方法实现算法,这些算法和算法的子部分是构成软件业务逻辑的最小知识块。你只需要保证这些块不重复即可。
在一个完美的应用程序中,每一小块业务逻辑将被封装在一个表征中,也就是一个变量或一个类。变量被封装在一个能够被描述为一个职责表征的类中,类被封装在一个能被描述为功能表征的组件中。这种方式称为模块化架构,DRY原则是其一个重要的部分。
实现DRY
你可以按照以下方式降低软件项目的复杂度,以便更容易地发现潜在的重复问题:
原则2:尽量简单、一目了然(Keep it Simple Stupid,KISS原则)
这里的Stupid翻译为“一目了然”更好一些,简单并不意味着一目了然,比如“.(){.|.&};.”,够简单吧,但看懂这是什么吗?这其实是一个bash中的fork炸弹(不断fork一个新进程,耗尽系统资源)。
所以做到简单的同时,还要做到一目了然。你也可以这样理解,将一个软件做得连白痴都会用。这就是用户体验的最高境界了。
如何做到简单且一目了然呢?这要归结到软件开发的可维护性和可理解性。KISS原则往往体现在需求设计阶段,当你考虑如何将客户的需求转变成一个可实现组件时,尝试确认以下部分:
原则3:适可而止(You Ain’t Gonna Need It,YAGNI原则)
YAGNI原则指的是只需要将应用程序必需的功能包含进来,而不要试图添加任何其他你认为可能需要的功能。
当你准备列出一个项目清单时,试着考虑以下问题:
英文原文:3 Key Software Principles You Must Understand
原则1:不要重复自己(Don’t Repeat Yourself,DRY原则)
这个原则非常重要,换言之,就是不要写重复的代码。
当你正在构建一个大型的软件项目时,你通常会被整体复杂性搞得不知所措。解决复杂性的最基本的策略是将系统分成若干个容易处理的部分。起初,你可能想将系统按组件划分,每个组件代表了一个子系统,其中包含了完成特定功能所需的一切。
组件还可以往下再分,这样复杂性将被降低到单一职责(single responsibility),每个职责可以使用一个类来实现,类包含了方法和属性。方法实现算法,这些算法和算法的子部分是构成软件业务逻辑的最小知识块。你只需要保证这些块不重复即可。
引用
DRY原则规定,在整个系统中,每一个小的知识块只可能发生一次,且每个知识块必须有一个单一、明确、权威的表征。
在一个完美的应用程序中,每一小块业务逻辑将被封装在一个表征中,也就是一个变量或一个类。变量被封装在一个能够被描述为一个职责表征的类中,类被封装在一个能被描述为功能表征的组件中。这种方式称为模块化架构,DRY原则是其一个重要的部分。
![](http://dl.iteye.com/upload/attachment/0069/9649/f8d78ec8-b60e-355a-b7eb-33dd5a330af3.png)
实现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%的功能上。
![](http://dl.iteye.com/upload/attachment/0069/9652/df725aa9-f0a2-3b6b-9fa3-52684b4e23b5.png)
当你准备列出一个项目清单时,试着考虑以下问题:
- 通过降低抽象的层级,来实现低复杂度
- 根据特性将功能独立出来
- 适度接受非功能性需求
- 识别耗时的任务,并摆脱它们
英文原文:3 Key Software Principles You Must Understand