一、高质量代码的三要素

可读性、可维护性、可变更性（所有软件理论的核心）

1.可读性强

1.1.why 程序员写不出可读性的代码？

原因有三：

• 他们很少关注代码的可读性，也对如何提高代码的可读性缺乏切身体会。
• 有时即使为代码编写了注释，也常常是注释语言晦涩难懂形同天书，令阅读者反复斟酌依然不明其意。
• 项目开发的时间往往是有限、紧急的。（可使用eclipse中的代码模板）

1.2.建议

　　1）不要编写大段的代码；　

　　　　在编码过程中，不断地对代码进行分段、分离，写成一个个函数，并要考虑这些函数应该放在哪里：是放在当前类呢，还是新建一个类？（遵循‘职责驱动原则’）

　　2）使用从上往下的编写方式

在编写代码的过程中，通常有两种不同的方式。一种是从下往上编写，也就是按照顺序，每分出去一个函数，都要将这个函数编写完，才回到主程序，继续往下编写。而一些更有经验的程序员会采用另外一种从上往下的编写方式。当他们在编写程序的时候，每个被分出去的程序，可以暂时只写一个空程序而不去具体实现功能。当主程序完成以后，再一个个实现它的所有子程序。采用这样的编写方式，可以使复杂程序有更好的规划，避免只见树木不见森林的弊病。

　　　　即，先把主结构、顺序写下来，然后再把其中的每一个方法给实现；

3）解释义名称与注释

我们在命名变量、函数、属性、类以及包的时候，应当仔细想想，使名称更加符合相应的功能。

使用最乱的就是get，因此我规定，get开头的函数仅仅用于获取类属性。

在编写代码时如果你编写的是一个接口或抽象类，我还建议你在@author后面增加@see注释，将该接口或抽象类的所有实现类列出来。

4）在编写代码过程中养成不断重构的习惯；（写到15-20行时，就要考虑是否需要重构）

2. 可维护性

能够适应软件在部署和使用中的各种情况

１）代码不能写死

• 使用日志文件、属性文件、配置文件，通常都是以下几个方式：将文件放到与类相同的目录，使用ClassLoader.getResource()来读取；将文件放到classpath目录下，用File的相对路径来读取；使用web.xml或另一个属性文件来制定读取路径。
• 使用相对路径存放相关文件；
• 不能在代码中写hardcode。

2）预测可能发生的变化

3）每次的变更尽量不要去修改原有的代码

3.可变更性

按照现在的软件理论，客户对软件的需求时时刻刻在发生着变化。

当软件设计好以后，为应对客户需求的变更而进行的代码修改，其所需要付出的代价，就是软件设计的可变更性。

由于软件合理的设计，修改所付出的代价越小，则软件的可变更性越好，即代码设计的质量越高。一种非常理想的状态是，无论客户需求怎样变化，软件只需进行适当的修改就能够适应。但这之所以称之为理想状态，因为客户需求变化是有大有小的。如果客户需求变化非常大，即使再好的设计也无法应付，甚至重新开发。然而，客户需求的适当变化，一个合理的设计可以使得变更代价最小化，延续我们设计的软件的生命力。

1）通过提高代码复用提高可维护性（初级）

代码规划方法：

• 对整个系统的整体分析与合理规划可以根本地保证代码复用。（需要高手：系统分析师（我的目标之一））

系统分析师通过用例模型、领域模型、分析模型的一步一步分析，最后通过正向工程，生成系统需要设计的各种类及其各自的属性和方法。采用这种方法，功能被合理地划分到这个类中，可以很好地保证代码复用。（这个我不熟悉）

• 通过开发人员在设计过程中的重构，也许更加实用。当某个开发人员在开发一段代码时，发现该功能与前面已经开发功能相同，或者部分相同。这时，这个开发人员可以对前面已经开发的功能进行重构，将可以通用的代码提取出来，进行相应的改造，使其具有一定的通用性，便于各个地方可以使用。

• 一些比较成功的项目组会指定一个专门管理通用代码的人，负责收集和整理项目组中各个成员编写的、可以通用的代码。

2）利用设计模式提高可变更性（中级）

a. if…else…

你应当想到你的代码应当重构一下了。

Java代码

X x = factory.getBean(var); x.doX();

这样就可以实现以上的功能了。我们看到这里有一个工厂，放着所有的A、B、C．．．并且与它们的key对应起来，并且写在配置文件中。如果出现新的选项时，通过修改配置文件就可以无限制的增加下去。

b.解决继承出现的问题，有一个最好的办法，就是采用策略模式。

将某一个影响更大的、或者选项更少的属性设计成继承类，而将其他属性设计成策略类，就可以解决很多继承类的问题。

3）职责驱动设计和领域驱动设计（高级）

前面我提到，当我们尝试写一些复杂功能的时候，我们把功能分解成一个个相对独立的函数。但是，应当将这些函数分配到哪个类中呢？也就是系统中的所有类都应当拥有哪些函数呢？或者说应当表现出哪些行为呢？

答案就在这里：以职责为中心，根据职责分配行为。

3.1.Responsibility Drive Design AND Domain Drive Design的提出

职责驱动设计（Responsibility Drive Design，RDD）是Craig Larman在他的经典著作《UML和模式应用》中提出的。

继Craig Larman提出的职责驱动设计数年之后，另一位大师提出了领域驱动设计。领域驱动设计（Domain Drive Design，DDD）是Eric Evans在他的同名著作《领域驱动设计》中提出的。

　　　　3.2.低表示差异

我们开发的应用软件实际上是对现实世界的模拟，因此，软件世界与现实世界存在着必然的联系。当我们在进行需求分析的时候，需求分析员实际上是从客户那里在了解现实世界事物的规则、工作的流程。

如果我们在软件分析和设计的过程中，将软件世界与现实世界紧密地联系到一起，我们的软件将更加本色地还原事物最本质的规律。这样的设计，就称之为“低表示差异”。

采用“低表示差异”进行软件设计，现实世界有什么事物，就映射为软件世界的各种对象（类）；现实世界的事物拥有什么样的职责，在软件世界里的对象就拥有什么样的职责；在现实世界中的事物，因为它的职责而产生的行为，在软件世界中就反映为对象所拥有的函数。

3.3.低耦合（耦合就是对某元素与其它元素之间的连接、感知和依赖的量度）、高内聚（功能内聚）、信息专家模式

3.4.领域分析和领域模型

我们在分析系统时，首先是根据客户需求进行用例分析，然后根据用例绘制领域模式和分析模型，整个系统最主要的类就形成了。通过以上分析形成的类，往往和现实世界的对象是对应的。正因为如此，软件世界的这些类也具有了与现实世界的对象相对应的职责，以及在这些职责范围内的行为。

在之前的设计理论中，领域模型是从用例模型到分析模型之间的一种中间模型，也就是从需求分析到软件开发之间的一种中间模型。

但是，Evans在领域驱动设计中，将它放到了一个无比重要的位置。按照领域驱动设计的理论，在需求分析阶段，需求分析人员使用领域模型与客户进行沟通；在设计开发阶段，开发人员使用领域模型指导设计开发；在运行维护和二次开发阶段，维护和二次开发人员使用领域模型理解和熟悉系统，并指导他们进行维护和二次开发。

总之，在整个软件开发的生命周期中，领域模型都成为了最核心的内容。（领域模型是一些类图，但是这些类是现实世界中的事物）

角色、职责、协作

理解了“低表示差异”，现在我们来看看我们应当如何运用职责驱动设计进行分析和设计。首先，我们通过与客户的沟通和对业务需求的了解，从中提取出现实世界中的关键事物以及相互之间的关系。这个过程我们通常通过建立领域模型来完成。领域模型建立起来以后，通过诸如Rational Rose这样的设计软件的正向工程，生成了我们在软件系统中最初始的软件类。这些软件类，由于每个都扮演着现实世界中的一个具体的角色，因而赋予了各自的职责。前面我已经提到，如果你的系统采用职责驱动设计的思想进行设计开发，作为一个好的习惯，你应当在每一个软件类的注释首行，清楚地描述该软件类的职责。

from：http://blog.jobbole.com/29764/