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
网友评论