软件编程基础规约
1. 概述
业界、指导编程的、经典书籍很多，如《重构》、《代码大全》、《设计模式》；更进一步的则有《敏捷软件开发》、《领域驱动设计》、《计算机程序的构造与解释》等等。这些书籍由浅入深的，有助于开发人员形成一整套的编程体系。
阅读这些书籍需要花费大量的精力，特别是《设计模式》、《领域驱动设计》、《计算机程序的构造与解释》。对于初学者来说有如天书，即便对于有经验的开发人员，想要看懂也并非易事。
另一方面，整个行业对软件开发人员的需求不断增加，人员能力参差不齐，软件质量无法保证。
本文尝试补齐开发人员能力和行业诉求之间的GAP。如果你是一名开发人员，尚未形成自己的编程体系。如果你正在开发产品功能需求，希望快速审视代码质量是否达到产品级标准。如果希望能更聚焦业务逻辑，而非基础编码的问题。那么，OK。
本文只此一篇，不是系列文章，也不会太长。本文将以最简短的方式，描述软件开发最基础、核心的六条编程规约。同时，文末还附赠了一条架构规约，当然这不是本文的重点。
2. 编程规约
- 规约1：分层设计
- 规约2：面向接口编程
- 规约3：业务数据建模
- 规约4：单一职责原则
- 规约5：精简原则
- 规约6： 生命周期最小化
2.1 规约1：代码分层设计
分层设计是编程的基础，首先要有一个合理的分层，才可能写出好的代码。那么什么才是好的分层设计？典型的代码分层又是什么样的呢？
好的分层设计应该包括如下几个特点：
- 上层只允许调用直接的下层，不允许跨层调用。
- 下层不允许调用上层，允许通过回调方式解耦。
- 平层之间调用不违反设计规则，但应尽量避免。
典型的代码分层设计如下：
典型分层设计
-
App：应用层。App层代表了对外的表现形态，一个模块可能有多个App层。例如模块对外提供了restful接口、rpc接口，那么它应该有两个App抽象。App层应尽可能的做薄，不做任何业务逻辑处理，只做入参校验、App层到Server层之间的模型转换。
-
Server：业务编排层。Server层负责核心业务的编排，它可以引用一个或者多个下层业务单元，即上图所示的Mgr类。如果业务足够简单，也可以将Server、Mgr层合并。此时Server层将变为业务处理层，而非业务编排层。
-
Mgr：业务单元层。对于复杂业务，需要采用分治方式，拆分为多个业务单元。这些业务单元有各种明确的职责，由Server层做统一编排。Server层和Mgr层存在一定的模糊边界，对于简单的逻辑Server层可以代劳，Server层的代码超过一定代码量(如300行)，需要考虑抽象新的Mgr对象。
-
Repository：数据仓储层。Repository层在Dao层之上，这一层抽象更多源于《领域驱动设计》。在早期的分层设计中，Dao层承载了数据访问抽象，Mgr层直接引用Dao层做数据存储，这样做使得Mgr层关注了一部分存储细节。引入Repository层之后，按业务数据模型构造Repository，通过Repository做数据存储访问，Mgr层集中关注业务逻辑处理。需要注意，Repository和Entity不是一一对应的，Root Entity及其附属的Entity可以共用一个Repository。Root Entity可以理解为核心业务实体对象，附属Entity可以理解为非核心的引用对象。关于这部分的详细描述，请参照《领域驱动设计》中“第5章 软件中所表示的模型”一文。
-
Dao：数据访问层。Dao层用于屏蔽部分数据库访问细节，而非全部。如使用MySql数据库访问的Dao层与使用MongoDB数据库访问的Dao层设计是不同的。Dao层只能尽量做到屏蔽底层细节，在复杂场景下完全屏蔽了底层细节将使得Dao层非常厚重。Repository层负责对上屏蔽全部数据存储细节。
-
Entity：业务数据模型。核心的业务数据建模，系统围绕数据模型编码业务。Entity的设计是整个业务的关键，关于这部分的详细说明参见“规约3：业务数据建模”。
-
Util：工具层。供模块或者产品使用的工具层，由多个类组成。这些工具类一般不依赖其他部件，或者只依赖轻量级部件。通常实现一些通用的逻辑处理，如IP地址校验、日期转换等。Util可以被任何层级调用，不属于分层结构中的任何一层。
-
Proxy：代理层。代理层用于代理其他模块提供的业务接口，该层抽象是按需构建的。如调用其他业务的restful接口需要构建参数，发起restful请求，判定网络异常等；可以提供一个代理层隐藏restful调用细节，使得外部看起来和本地调用没有任何区别。如果对于简单的api接口调用可省略Proxy封装。
2.2 规约2：面向接口编程
面向接口编程的核心诉求是信息隐藏，上层只关心和下层签订的“契约(接口)”。接口定义了需要提供哪些能力，而至于如何提供了这些能力上层不感知、也不关心。
这样做的带来的好处：解耦，下层可以选择任意方式实现“契约”。上层将全部精力关注到业务逻辑，如此方可开发出复杂、稳定的产品。
但落实到实现上，如果所有分层(最上层除外)都严格遵守接口、实现分离，不现实也不合适。每多一层抽象，就增加了代码的复杂度。这里涉及抽象粒度、时机：如何面向接口编程，同时减少不必要的接口抽象？
以我个人的经验来看，处理方式如下：
- 如果接口只有一个实现，可省略接口定义。以实现类的public方法做为接口定义，其他非接口方法声明为protected或private。
- 如果接口有多个实现，增加接口抽象。上层创建下层对象时可以通过new、工厂方法、工厂类等方式实现。上层使用下层对象时，使用的是接口对象。至于选择哪种方式，需要根据具体情况而定。
2.3 规约3：业务数据建模
任何一个业务功能都有其业务模型，即核心Entity抽象。大部分人在开发过程中，更关心的是逻辑、代码分支处理，而忽略了业务数据建模。最终，代码可以实现当前的功能诉求，但无法持续演进，新功能开发将导致大量既有代码变更。
因此我们强调，在开发之前，需要先对领域建模。本文讨论的是模块级的代码开发，而非系统级设计。对于一个功能模块来说，核心的数据模型(Entity)可能只有1-5个，一切的业务行为应围绕业务数据模型展开。
比如对于告警管理模块，核心的业务数据模型包括：当前告警Entity、历史告警Entity、事件Entity。告警管理业务围绕三个Enttiy展开，如告警清除，实际上只是从当前告警Entity到历史告警Entity的状态迁移。
典型的业务数据Entity具有如下几个特点：
- 和业务领域中的一个或多个术语对应。
- 具有唯一标识，可以是流水号、UUID、身份证号等各种形式。
- 模块或领域内唯一。对于大型系统，系统级统一建模会很困难，不同的开发团队必然会独自演进各自的业务模型。按《领域驱动设计》一书中的建议，我们需要做到Bounded Context内的统一模型，Bound Context通常指的就是一个业务模块。
- 业务数据Entity必须做到字段的不可精简。Entity中的每一个字段代表了一个业务属性，需要审视每一个字段新增、删除是否影响Entity的业务表达。保证业务数据模型的稳定性，避免频繁变更。
除Entity外，还有一种业务数据模型称之为Value Object。Value Object没有唯一标识，通常附属在一个或者多个Entity之中。如Address附属在个人信息中时，属于Value Object。关于Entity、Value Object可参看《领域驱动设计》。
落到实现上，还有一个问题需要解决：代码是分层解耦、面向接口编程的，但Entity需要统一建模、跨层，二者互相矛盾。
这样说可能不够直接，举个例子：
class DemoApp
{
private DemoServer demoServer = new DemoServer();
public BusinessDto getBusinessData()
{
BusinessEntity entity = demoServer.getBusinessData();
//类型转换
return convertToDto(entity);
}
}
class DemoServer
{
private DemoDao demoDao = new DemoDao();
public BusinessEntity getBusinessData()
{
//注：此处省略了repository，直接使用了dao层
return demoDao.queryBusinessData();
}
}
@Entity
@Table(name="tbl_sky")
class BusinessEntity
{
@Id
private int id;
@Column(name="OPTLOCK")
private string data;
public int getId() { return id; }
public void setId(int id) { this.id = id; }
public string getData() { return data; }
public void setData(string data) { this.data = data; }
}
各位有没有看出上面代码的问题？
- BusinessEntity是数据库实体类，Server层直接向上返回，破坏了信息隐藏原则。App层感知了底层依赖的Hibernate，App层被污染。
- Server层业务数据模型和数据库存储Entity抽象绑定，二者无法独立演进。底层抽象和存储介质相关，而业务数据模型只应和领域相关。举例来说，如果底层由MySql切换至MongoDB后，数据库Entity抽象变更，但Server层及之上的业务数据建模不应发生任何改变。
业界通常的做法是：一个业务数据按分层做多次建模，以保证分层解耦。如App层不会直接拿到Dao层的Entity，而是经过Server层转换后的另外一个Entity对象。这样就会导致同一个业务数据存在多个Entity对象，代码中充斥着大量的核心业务无关的转换逻辑。这增加了维护成本，提高了出错的可能性。我认为合理的做法应该是下面这样：
class DemoApp
{
private DemoServer demoServer = new DemoServer();
public BusinessDto getBusinessData()
{
BusinessEntity entity = demoServer.getBusinessData();
//类型转换
return convertToDto(entity);
}
}
class DemoServer
{
private DemoDao demoDao = new DemoDao();
public IBusinessEntity getBusinessData()
{
//注：此处省略了repository，直接使用了dao层
return demoDao.queryBusinessData();
}
}
interface IBusinessEntity
{
public int getId();
public string getData();
}
@Entity
@Table(name="tbl_sky")
class BusinessEntity implements IBusinessEntity
{
@Id
private int id;
@Column(name="OPTLOCK")
private string data;
public int getId() { return id; }
public void setId(int id) { this.id = id; }
public string getData() { return data; }
public void setData(string data) { this.data = data; }
}
说明如下：
- 增加业务接口类IBusinessEntity抽象层，Server返回该接口类，而非数据库实体类，做到对上信息隐藏。
- BusinessEntity继承IBusinessEntity接口，用作数据库实体类。
- 业务数据接口类和数据库实体类分离后，二者可以独立演进，互不影响。同时，当业务数据接口类内容是数据库实体类的子集时，二者又可以自然的保持一致。
- 业务数据接口类只提供get方法，使得业务数据天然具备了immutable特性，避免上层修改污染到下层。
- 如有必要，我们可以为业务数据接口类增加一个Builder，通过Builder构建业务数据接口对象。通常，只有在引入Repository层时才需要，这里不再详述。
2.4 规约4：单一职责原则。
单一职责原则：就一个类而言，应该仅有一个引起它变化的原因；我们把职责定义为“变化的原因”。
--- 《敏捷软件开发》
单一职责原则就是我们常说的“分治”，组成软件系统的每个部分各司其职，协同完成复杂的系统任务。狭义来讲，单一职责原则用于指导分层、接口定义；按单一职责原则审视分层、接口定义的合理性。
而从更广泛的软件系统设计、实现角度来看，单一职责原则可做如下场景审视：
- 变量含义是否唯一。变量名称和实际使用语义保持一致，不要为了节省变量将一个变量用作其他含义。
- 函数职责是否唯一。函数职责和函数名称定义是否一致，是否存在超越函数定义的逻辑。典型的错误包括：get方法中修改对象状态；函数中包含了可被进一步抽象的子函数实现，使得函数本身应当实现的业务逻辑不够清晰等。
- 类职责是否唯一。类抽象本身是否合理，类职责和类名称定义是否一致，是否只有一个引起该类变化的修改点。举个例子，定义了一个常量类LicenseConstant，用于维护License机制中用到的常量定义，整个License机制共享该类：
class LicenseConstants
{
private String ROOT_PATH = "/root/lcs";
private String ESN = "esn";
......
}
这是一段违反单一职责原则的经典案例。首先，类抽象本身就很有问题：LicenseConstants无法对应到现实世界、抽象概念中的任意实体，在业务建模阶段，你不可能构建这样一个模型对象。其次，整个License模块都可能是该类的修改点，如增加配置文件、资源项定义等各种场景。
再往上如模块、微服务、服务等也应遵循单一职责原则。其思考维度大同小异。
2.5 规约5：精简原则
一本书的完成，不在它不能加入任何内容的时候，而在不能再删去任何内容的时候。
----伏尔泰
生活中，我们希望在完成一件事时花费最少。其实，编码也是一样，好的程序员要对代码“吝啬”。完成同样的功能，我们希望自己编写的代码最少、最稳定、可读性最高。每一行代码经过精雕细琢后，将会深深的印在你的脑海里。
本节没有示例，只列出几个重要的检查项，开发人员在编码时懂得自省才是最重要的：
- 是否存在重复代码可被抽象复用。不是所有的重复代码均应被抽象，可抽象的复用单元应具备业务合理性、提升代码可读性、抽象稳定性等特点。
- 多分支是否可合并处理。如swtich\case中多个case是否可合并，是否有多个if的处理流程可合并等等。
- 是否引入了不必要的依赖。即低扇出原则，一个类应尽量少的依赖外部类，提升该类的稳定性。
- 高扇入原则。抽象类应尽可能的被复用，而不是重复造轮子。
- 代码深度是否可进一步降低。包括代码深度、圈复杂度等。
-
是否有更简单的实现方式。
示例：找到type为grocery的所有交易，返回按交易值降序排序后的ID集合
//找到type为grocery的所有交易
List<Transaction> groceryTrans = new Arraylist<>();
for(Transaction t: transactions){
if(t.getType() == Transaction.GROCERY) {
groceryTrans.add(t);
}
}
//按交易值降序排序
Collections.sort(groceryTrans, new Comparator(){
public int compare(Transaction t1, Transaction t2) {
return t2.getValue().compareTo(t1.getValue());
}
});
//获取ID集合
List<Integer> transIds = new ArrayList<>();
for(Transaction t: groceryTrans){
transIds.add(t.getId());
}
采用Java8的Lambda、Stream的实现如下：
List<Integer> transIds = transactions.
parallelStream().
filter(t -> t.getType() == Transaction.GROCERY). //找到type为grocery的所有交易
sorted(comparing(Transaction::getValue).reversed()). //按交易值降序排序
map(Transaction::getId). //获取ID集合
collect(toList()); //以List形式返回
2.6 规约6：生命周期最小化原则
不知道各位有没有这样的体验：在编程阶段，大脑中模拟程序运行，并验证结果是否符合预期，从而调整代码。在定位问题时也是一样：测试描述操作步骤和问题现象，在脑中构想程序运行经过的分支，推测可能出现问题的代码段。如果有过上述的经历，说明对于编程至少已经入门。反过来，对于一切问题定位都依赖日志、调试信息的开发人员，我只想说：换一个行业，希望还来得及。
继续刚才的话题，如果希望模拟结果正确，代码必须精简，同时系统运行状态可控。关于代码精简可参见上一规约，运行状态可控就是本节要讲的生命周期最小化。
系统运行状态管理，说的简单点就是变量生命周期管理。程序中每个变量代表了一种可变状态，后端代表的实体可能是内核锁资源、内存数据、文件、数据库、网络等等。程序在运行过程中，这些数据不断变化，共同组成了系统的运行状态。变量越多、生命周期越长，系统越复杂、越不容易稳定。
我们希望尽量控制变量的数量和生命周期，使系统具备“可追踪性”。变量的作用域越大，变量的“可追踪性”越弱。对于变量使用的优先级应该是：无变量 > 局部变量 > 成员变量 > 全局变量(静态变量)。
- 无变量：无需管理变量状态。
- 局部变量：生命周期控制在函数或者{}内部，如果整个函数只依赖局部变量，那么对于固定的输入，输出也是固定的。只需要在函数(或{})内管理变量。
- 成员变量：生命周期控制在对象内，对象内的多个函数共享成员变量，并发场景下需要做并发保护。
- 全局变量(静态变量)：全局变量始于该变量的首次使用，直至系统运行结束(或显示卸载)；该类型的所有对象均可修改全局变量(静态变量)。
上面的表述直接、简单，但没讲具体怎么做。下面列几个典型的、违反可追踪性的示例加以说明：
-
示例：将成员变量降至局部变量
可降至局部变量的成员变量应局部如下特点：
1.a) 成员变量本身不是对象的核心属性
1.b) 成员变量只被一个对外(public)方法使用，其余方法不使用或仅private方法使用。
违规代码：
class DemoClass
{
private int xx;
public void doSomething(int param)
{
//do ...
xx = calcData(param);
doAnotherThing();
}
private void doAnotherThing()
{
switch(xx)
{
case 0:
//...
break;
case 1:
//...
break;
}
}
}
修改后：
class DemoClass
{
public void doSomething(int param)
{
//do ...
int xx = calcData(param);
doAnotherThing(xx);
}
private void doAnotherThing(int xx)
{
switch(xx)
{
case 0:
//...
break;
case 1:
//...
break;
}
}
}
- 示例：成员变量生命周期放大
我们说一个变量是成员变量时，强调的一定是它的“成员”属性，也就是说这个变量是类对象的一员，那么它就不应该脱离类对象的管控。一旦将该成员变量做为引用对象对外暴露后，该成员变量的生命周期就被扩大了，具备了“全局”属性。这样做有如下几个坏处：
- 成员变量的声明周期大于所属对象的声明周期，所属对象销毁后，其“”成员变量”依旧存活。
- 成员变量可不经过所属对象直接做状态变更，状态变更难以跟踪。
违规代码：
class Resource
{
private int num;
private String name;
public void setNum(int num) { this.num = num; }
public int getNum() { return num; }
public void setName(String name) { this.name = name; }
public String getName() { return name; }
}
class ResourceMgr
{
private List<Resource> resources;
public List<Resource> getResources()
{
return resources;
}
}
class DemoClass
{
public void doSomething()
{
List<Resource> resources = ResourceMgr.getInstance().getResources();
for(Resource resource : resources)
{
if (resource.getName().equals("xxx"))
{
//do business with resource
return;
}
}
}
}
ResourceMgr管理一组Resource对象，但其却将内部管理的的resources列表直接返回至外部，成员变量生命周期被放大。一种可能的修改方案如下：
class ResourceMgr
{
private List<Resource> resources;
public List<Resource> find(String name)
{
return resources.stream().filter((resource) -> {
return resource.getName().equals(name);
}).findFirst().orElse(null);
}
}
class DemoClass
{
public void doSomething()
{
Resource resource = ResourceMgr.getInstance().find("xxx");
if (resource == null)
{
return ;
}
///do business with resource
}
}
该方案提供一个查询接口，返回符合条件的资源对象。看似避免resources对外暴露，但返回的对象依旧为成员变量，本质上并无差别。真正合理的修改方案如下：
class Resource implements Cloneable { //!!!注意这里
private int num;
private String name;
public void setNum(int num) {
this.num = num;
}
public int getNum() {
return num;
}
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
@Override
public Resource clone() throws CloneNotSupportedException {
return (Resource) super.clone();
}
}
class ResourceMgr {
private static ResourceMgr instance = new ResourceMgr();
private List<Resource> resources = new ArrayList<>();
private ResourceMgr() {
}
public static ResourceMgr getInstance() {
return instance;
}
public Resource find(String name) {
//查找符合条件的数据
Resource resource = resources.stream().filter((r) -> {
return r.getName().equals(name);
}).findFirst().orElse(null);
if (resource == null) {
return null;
}
//!!!注意这里
//返回cloneable对象
try {
return resource.clone();
} catch (CloneNotSupportedException e) {
return null;
}
}
}
class DemoClass
{
public void doSomething()
{
Resource resource = ResourceMgr.getInstance().find("xxx");
if (resource == null)
{
return ;
}
///do business with resource
}
}
为Resource实现Cloneable方法，find返回cloneable对象而非成员变量本身，有效避免成员变量的生命周期被放大。另外一种修改方案：
//!!!注意这里
interface IResource
{
int getNum();
String getName();
}
//！！！注意这里
class Resource implements IResource {
private int num;
private String name;
public void setNum(int num) {
this.num = num;
}
public int getNum() {
return num;
}
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
class ResourceMgr {
private static ResourceMgr instance = new ResourceMgr();
private List<Resource> resources = new ArrayList<>();
private ResourceMgr() {
}
public static ResourceMgr getInstance() {
return instance;
}
//！！！注意这里
public IResource find(String name) {
//查找符合条件的数据
return resources.stream().filter((r) -> {
return r.getName().equals(name);
}).findFirst().orElse(null);
}
}
class DemoClass
{
public void doSomething()
{
//注意这里
IResource resource = ResourceMgr.getInstance().find("xxx");
if (resource == null)
{
return ;
}
///do business with resource
}
}
抽象一个接口类，find时返回接口IResource而非实现Resource对象。此时，成员变量的生命周期被放大，但对象的状态变更依旧在所属对象的控制之内。二者各有优缺点，到底使用哪种方案要根据具体使用场景而定。
上述两种方案都尝试解决控制成员变量的生命周期和状态变更的“可追踪性”，但如果我们期望的是更新符合find条件的对象，此时上述两种方案均不可取，而应在ResourceMgr中提供相应的接口，如下：
class ResourceMgr {
private static ResourceMgr instance = new ResourceMgr();
private List<Resource> resources = new ArrayList<>();
private ResourceMgr() {
}
public static ResourceMgr getInstance() {
return instance;
}
public boolean update(String name, int num) {
Resource resource = resources.stream().filter((r) -> {
return r.getName().equals(name);
}).findFirst().orElse(null);
if (resource == null) {
return false;
}
resource.setNum(num);
return true;
}
}
- 示例：控制局部变量的生命周期
成员变量的生命周期控制在函数内部，因为其生命周期本身较短，我们通常疏于管理，使得生命周期放大，可读性降低。
违规代码：
public void doSomething(List<Resource> resources, List<Device> devices) {
int resourceChecksum = 0;
int deviceChecksum = 0;
int resourceTotal = 0;
int deviceTotal = 0;
int resourceAverage = 0;
int deviceAverage =0;
StringBuilder resourceStringBuilder = new StringBuilder();
StringBuilder deviceStringBuilder = new StringBuilder();
//计算resource的average、checksum
for (Resource resource : resources) {
resourceStringBuilder.append(resource.getName());
resourceTotal += resource.getNum();
}
resourceChecksum = resourceStringBuilder.toString().hashCode();
resourceAverage = resourceTotal / resources.size();
//计算device的average、checksum
for (Device device : devices) {
deviceStringBuilder.append(device);
deviceTotal += device.getNum();
}
deviceChecksum = deviceStringBuilder.toString().hashCode();
deviceAverage = deviceTotal / devices.size();
doAnoterThing(resourceChecksum, resourceAverage, deviceChecksum, deviceAverage);
}
上述代码将所有的变量声明定义在函数顶部，但和device相关的变量只有在计算device时才需要，生命周期被放大。针对这点，可以做如下修改：
public void doSomething(List<Resource> resources, List<Device> devices) {
int resourceChecksum = 0;
int resourceTotal = 0;
int resourceAverage = 0;
StringBuilder resourceStringBuilder = new StringBuilder();
//计算resource的average、checksum
for (Resource resource : resources) {
resourceStringBuilder.append(resource.getName());
resourceTotal += resource.getNum();
}
resourceChecksum = resourceStringBuilder.toString().hashCode();
resourceAverage = resourceTotal / resources.size();
int deviceChecksum = 0;
int deviceTotal = 0;
int deviceAverage =0;
StringBuilder deviceStringBuilder = new StringBuilder();
//计算device的average、checksum
for (Device device : devices) {
deviceStringBuilder.append(device.getIdentifier());
deviceTotal += device.getNum();
}
deviceChecksum = deviceStringBuilder.toString().hashCode();
deviceAverage = deviceTotal / devices.size();
doAnoterThing(resourceChecksum, resourceAverage, deviceChecksum, deviceAverage);
}
device相关变量生命周期缩小，可读性提高，但代码看起来还是不够整洁。仔细分析代码的最后一行，我们只需要resourceChecksum, resourceAverage, deviceChecksum, deviceAverage，但函数的生命周期中却增加了两个stringbuilder和两个total变量。我们期望这些临时变量的生命周期进一步降低，如下：
public void doSomething(List<Resource> resources, List<Device> devices) {
//计算resource的average、checksum
int resourceChecksum = 0;
int resourceAverage = 0;
{
int total = 0;
StringBuilder stringBuilder = new StringBuilder();
for (Resource resource : resources) {
stringBuilder.append(resource.getName());
total += resource.getNum();
}
resourceChecksum = stringBuilder.toString().hashCode();
resourceAverage = total / resources.size();
}
//计算device的average、checksum
int deviceChecksum = 0;
int deviceAverage =0;
{
int total = 0;
StringBuilder stringBuilder = new StringBuilder();
for (Device device : devices) {
stringBuilder.append(device.getIdentifier());
total += device.getNum();
}
deviceChecksum = stringBuilder.toString().hashCode();
deviceAverage = total / devices.size();
}
doAnoterThing(resourceChecksum, resourceAverage, deviceChecksum, deviceAverage);
}
经过二次重构后，我们不但降低了sting builder和total变量的生命周期，也避免了名称污染。不同场景下的string builder和total可以同名，代码可读性进一步提升。关于使用{}控制生命周期的技巧还有很多，不再一一列举。
3. 架构规约
- 规约7：针对扩展点编程
3.7 规约7：针对扩展点编程
你愚弄了我一次，可耻的是你；但如果你愚弄了我两次，可耻的是我。
----《福尔摩斯：基本演绎法》
首先声明，这是一条附赠规约，不是说它不重要，而是因为以本文的篇幅，不可能讲通。针对扩展点编程是一个很大的话题，大到《设计模式》要花整本书来讲。本文只能提供一些指导建议，希望能有所帮助。
本节，我们讨论两个问题：什么是扩展点？以及如何针对扩展点编程？
-
什么是扩展点？
扩展点也称之为变化点，指的是软件中频繁变化的那一部分。系统中哪部分需求最活跃，那这部分就是系统的扩展点的来源。将需求映射到现有的系统业务模型，需要修改的那部分代码就是扩展点实现。
最理想的效果是：整个系统框架为所有的扩展点都做了预留，后续需求开发只需要在预留的“slot”上完成，系统框架不需要做任何变更。要达到这个效果，我们就需要具备预知能力，预知系统的演进方向、潜在需求等等。
对未来准确预知是不可能的，所以不存在完美的架构。构造出持续演进的框架是有可能的，但依然非常困难，你需要具备如下能力：- 业务建模的能力。首先，你要是一个业务专家。熟悉你所在行业，并能提炼出准确的业务模型。
- 基于功能、质量属性架构的能力。功能来源于用户需求，质量属性指的是性能、安全、可扩展性、可用性、一致性等等。很多质量属性是相互矛盾的，典型的如CAP理论。如何选择质量属性，在满足功能需求的同时，最大程度匹配系统的演进方向。
- 对扩展点的把控力。并不是所有的需求都会成为系统的扩展点，好的设计人员有能力评判断哪些需求能成为扩展点，而哪些不能。错失扩展点抽象，将会影响系统的稳定性；增加无谓的扩展点，将增加维护成本，不利于对整个系统的理解。
-
持续演进的能力。一个基于持续演进架构的、稳定的系统，其需求量和代码量之间不应该呈现出线性关系，而是逐渐收敛的。
其实，系统的扩展点也大致遵循上述原则。我们强调持续演进，时刻考虑推翻之前的部分架构设计，用更符合当前系统演进的架构替代，保持系统的生命力。
至于如何挖掘扩展点，建议参考《敏捷软件开发--原则、模式与实践》、《领域驱动设计》。
-
如何和针对扩展点编程？
一旦你有能力识别扩展点，那么针对扩展点编程就变得很容易了。
针对扩展点编程最主要的一个指导原则：开放封闭原则(OCP)。OCP的标准定义为：针对修改封闭，针对扩展开放。用通俗的话来说，如果有一个新的需求，我们期望达到如下效果：现有代码一行不改(或极少改动)，在现有代码基础上通过增加新的类或配置的方式实现需求功能。
关于OCP原则，《敏捷软件开发--原则、模式与实践》的第九章有详细描述，本文不再赘述。另外，GOF的《设计模式》就是从实践中总结出来的、针对扩展点编程的具体方法，业界的经典之作。
4. 总结
本文讲了6条基本编程规约、1条架构指导规约。我尝试以最少的文字描述，帮助一线开发人员提升编码能力，但最后文章的篇幅还是超出了我的预期。
同样，限于本文的篇幅，有太多的细节没有展开，好在有前辈早已帮我们整理成文。如本文最开始说的，如果你真正的想提高自身的编码、架构能力，请仔细翻阅以下书籍(建议按先后顺序阅读)：
(完)
【转载请注明】随安居士. 软件编程基础规约. 2018.06.13
