软件编程基础规约

比如对于告警管理模块，核心的业务数据模型包括：当前告警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需要统一建模、跨层，二者互相矛盾。

这样说可能不够直接，举个例子：

classDemoApp{ privateDemoServer demoServer = newDemoServer(); publicBusinessDto getBusinessData(){ BusinessEntity entity = demoServer.getBusinessData(); //类型转换returnconvertToDto(entity); }} classDemoServer{ privateDemoDao demoDao = newDemoDao(); publicBusinessEntity getBusinessData(){ //注：此处省略了repository，直接使用了dao层returndemoDao.queryBusinessData(); }} @Entity@Table(name= "tbl_sky") classBusinessEntity{ @Idprivateintid; @Column(name= "OPTLOCK") privatestring data; publicintgetId(){ returnid; } publicvoidsetId(intid){ this.id = id; } publicstring getData(){ returndata; } publicvoidsetData(string data){ this.data = data; }}

各位有没有看出上面代码的问题？

业界通常的做法是：一个业务数据按分层做多次建模，以保证分层解耦。如App层不会直接拿到Dao层的Entity，而是经过Server层转换后的另外一个Entity对象。这样就会导致同一个业务数据存在多个Entity对象，代码中充斥着大量的核心业务无关的转换逻辑。这增加了维护成本，提高了出错的可能性。我认为合理的做法应该是下面这样：

classDemoApp{ privateDemoServer demoServer = newDemoServer(); publicBusinessDto getBusinessData(){ BusinessEntity entity = demoServer.getBusinessData(); //类型转换returnconvertToDto(entity); }} classDemoServer{ privateDemoDao demoDao = newDemoDao(); publicIBusinessEntity getBusinessData(){ //注：此处省略了repository，直接使用了dao层returndemoDao.queryBusinessData(); }} interfaceIBusinessEntity{ publicintgetId(); publicstring getData();} @Entity@Table(name= "tbl_sky") classBusinessEntityimplementsIBusinessEntity{ @Idprivateintid; @Column(name= "OPTLOCK") privatestring data; publicintgetId(){ returnid; } publicvoidsetId(intid){ this.id = id; } publicstring getData(){ returndata; } publicvoidsetData(string data){ this.data = data; }}

说明如下：

• 增加业务接口类IBusinessEntity抽象层，Server返回该接口类，而非数据库实体类，做到对上信息隐藏。
• BusinessEntity继承IBusinessEntity接口，用作数据库实体类。
• 业务数据接口类和数据库实体类分离后，二者可以独立演进，互不影响。同时，当业务数据接口类内容是数据库实体类的子集时，二者又可以自然的保持一致。
• 业务数据接口类只提供get方法，使得业务数据天然具备了immutable特性，避免上层修改污染到下层。
• 如有必要，我们可以为业务数据接口类增加一个Builder，通过Builder构建业务数据接口对象。通常，只有在引入Repository层时才需要，这里不再详述。

单一职责原则：就一个类而言，应该仅有一个引起它变化的原因；我们把职责定义为“变化的原因”。

--- 《敏捷软件开发》

单一职责原则：就一个类而言，应该仅有一个引起它变化的原因；我们把职责定义为“变化的原因”。

--- 《敏捷软件开发》

单一职责原则就是我们常说的“分治”，组成软件系统的每个部分各司其职，协同完成复杂的系统任务。狭义来讲，单一职责原则用于指导分层、接口定义；按单一职责原则审视分层、接口定义的合理性。

而从更广泛的软件系统设计、实现角度来看，单一职责原则可做如下场景审视：

• 变量含义是否唯一。变量名称和实际使用语义保持一致，不要为了节省变量将一个变量用作其他含义。
• 函数职责是否唯一。函数职责和函数名称定义是否一致，是否存在超越函数定义的逻辑。典型的错误包括：get方法中修改对象状态；函数中包含了可被进一步抽象的子函数实现，使得函数本身应当实现的业务逻辑不够清晰等。
• 类职责是否唯一。类抽象本身是否合理，类职责和类名称定义是否一致，是否只有一个引起该类变化的修改点。举个例子，定义了一个常量类LicenseConstant，用于维护License机制中用到的常量定义，整个License机制共享该类：

这是一段违反单一职责原则的经典案例。首先，类抽象本身就很有问题：LicenseConstants无法对应到现实世界、抽象概念中的任意实体，在业务建模阶段，你不可能构建这样一个模型对象。其次，整个License模块都可能是该类的修改点，如增加配置文件、资源项定义等各种场景。

再往上如模块、微服务、服务等也应遵循单一职责原则。其思考维度大同小异。

2.5 规约5：精简原则

一本书的完成，不在它不能加入任何内容的时候，而在不能再删去任何内容的时候。

----伏尔泰

一本书的完成，不在它不能加入任何内容的时候，而在不能再删去任何内容的时候。

----伏尔泰

生活中，我们希望在完成一件事时花费最少。其实，编码也是一样，好的程序员要对代码“吝啬”。完成同样的功能，我们希望自己编写的代码最少、最稳定、可读性最高。每一行代码经过精雕细琢后，将会深深的印在你的脑海里。

本节没有示例，只列出几个重要的检查项，开发人员在编码时懂得自省才是最重要的：

• 是否存在重复代码可被抽象复用。不是所有的重复代码均应被抽象，可抽象的复用单元应具备业务合理性、提升代码可读性、抽象稳定性等特点。
• 多分支是否可合并处理。如swtichcase中多个case是否可合并，是否有多个if的处理流程可合并等等。
• 是否引入了不必要的依赖。即低扇出原则，一个类应尽量少的依赖外部类，提升该类的稳定性。
• 高扇入原则。抽象类应尽可能的被复用，而不是重复造轮子。
• 代码深度是否可进一步降低。包括代码深度、圈复杂度等。
• 是否有更简单的实现方式。 示例：找到type为grocery的所有交易，返回按交易值降序排序后的ID集合

采用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：生命周期最小化原则

不知道各位有没有这样的体验：在编程阶段，大脑中模拟程序运行，并验证结果是否符合预期，从而调整代码。在定位问题时也是一样：测试描述操作步骤和问题现象，在脑中构想程序运行经过的分支，推测可能出现问题的代码段。如果有过上述的经历，说明对于编程至少已经入门。反过来，对于一切问题定位都依赖日志、调试信息的开发人员，我只想说：换一个行业，希望还来得及。

继续刚才的话题，如果希望模拟结果正确，代码必须精简，同时系统运行状态可控。关于代码精简可参见上一规约，运行状态可控就是本节要讲的生命周期最小化。

系统运行状态管理，说的简单点就是变量生命周期管理。程序中每个变量代表了一种可变状态，后端代表的实体可能是内核锁资源、内存数据、文件、数据库、网络等等。程序在运行过程中，这些数据不断变化，共同组成了系统的运行状态。变量越多、生命周期越长，系统越复杂、越不容易稳定。

我们希望尽量控制变量的数量和生命周期，使系统具备“可追踪性”。变量的作用域越大，变量的“可追踪性”越弱。对于变量使用的优先级应该是：无变量 > 局部变量 > 成员变量 > 全局变量(静态变量)。

• 无变量：无需管理变量状态。
• 局部变量：生命周期控制在函数或者{}内部，如果整个函数只依赖局部变量，那么对于固定的输入，输出也是固定的。只需要在函数(或{})内管理变量。
• 成员变量：生命周期控制在对象内，对象内的多个函数共享成员变量，并发场景下需要做并发保护。
• 全局变量(静态变量)：全局变量始于该变量的首次使用，直至系统运行结束(或显示卸载)；该类型的所有对象均可修改全局变量(静态变量)。

上面的表述直接、简单，但没讲具体怎么做。下面列几个典型的、违反可追踪性的示例加以说明：

违规代码：

classDemoClass{privateintxx; publicvoiddoSomething(intparam){ //do ...xx = calcData(param); doAnotherThing(); } privatevoiddoAnotherThing(){ switch(xx) { case0: //...break; case1: //...break; } }}

修改后：

classDemoClass{publicvoiddoSomething(intparam){ //do ...intxx = calcData(param); doAnotherThing(xx); } privatevoiddoAnotherThing(intxx){ switch(xx) { case0: //...break; case1: //...break; } }}

我们说一个变量是成员变量时，强调的一定是它的“成员”属性，也就是说这个变量是类对象的一员，那么它就不应该脱离类对象的管控。一旦将该成员变量做为引用对象对外暴露后，该成员变量的生命周期就被扩大了，具备了“全局”属性。这样做有如下几个坏处：

违规代码：

classResource{ privateintnum; privateString name; publicvoidsetNum(intnum){ this.num = num; } publicintgetNum(){ returnnum; } publicvoidsetName(String name){ this.name = name; } publicString getName(){ returnname; }} classResourceMgr{ privateList<Resource> resources; publicList<Resource> getResources(){ returnresources; }} classDemoClass{ publicvoiddoSomething(){ List<Resource> resources = ResourceMgr.getInstance().getResources(); for(Resource resource : resources) { if(resource.getName().equals( "xxx")) { //do business with resourcereturn; } } }}

ResourceMgr管理一组Resource对象，但其却将内部管理的的resources列表直接返回至外部，成员变量生命周期被放大。一种可能的修改方案如下：

classResourceMgr{ privateList<Resource> resources; publicList<Resource> find(String name){ returnresources.stream().filter((resource) -> { returnresource.getName().equals(name); }).findFirst().orElse( null); }} classDemoClass{ publicvoiddoSomething(){ Resource resource = ResourceMgr.getInstance().find( "xxx"); if(resource == null) { return; } ///do business with resource}}

该方案提供一个查询接口，返回符合条件的资源对象。看似避免resources对外暴露，但返回的对象依旧为成员变量，本质上并无差别。真正合理的修改方案如下：

classResourceimplementsCloneable{ //!!!注意这里privateintnum; privateString name; publicvoidsetNum(intnum){ this.num = num; } publicintgetNum(){ returnnum; } publicvoidsetName(String name){ this.name = name; } publicString getName(){ returnname; } @OverridepublicResource clone()throwsCloneNotSupportedException { return(Resource) super.clone(); }} classResourceMgr{ privatestaticResourceMgr instance = newResourceMgr(); privateList<Resource> resources = newArrayList<>(); privateResourceMgr(){ } publicstaticResourceMgr getInstance(){ returninstance; } publicResource find(String name){ //查找符合条件的数据Resource resource = resources.stream().filter((r) -> { returnr.getName().equals(name); }).findFirst().orElse( null); if(resource == null) { returnnull; } //!!!注意这里//返回cloneable对象try{ returnresource.clone(); } catch(CloneNotSupportedException e) { returnnull; } }} classDemoClass{ publicvoiddoSomething(){ Resource resource = ResourceMgr.getInstance().find( "xxx"); if(resource == null) { return; } ///do business with resource}}

为Resource实现Cloneable方法，find返回cloneable对象而非成员变量本身，有效避免成员变量的生命周期被放大。另外一种修改方案：

//!!!注意这里interfaceIResource{ intgetNum(); String getName();} //！！！注意这里classResourceimplementsIResource{ privateintnum; privateString name; publicvoidsetNum(intnum){ this.num = num; } publicintgetNum(){ returnnum; } publicvoidsetName(String name){ this.name = name; } publicString getName(){ returnname; }} classResourceMgr{ privatestaticResourceMgr instance = newResourceMgr(); privateList<Resource> resources = newArrayList<>(); privateResourceMgr(){ } publicstaticResourceMgr getInstance(){ returninstance; } //！！！注意这里publicIResource find(String name){ //查找符合条件的数据returnresources.stream().filter((r) -> { returnr.getName().equals(name); }).findFirst().orElse( null); }} classDemoClass{ publicvoiddoSomething(){ //注意这里IResource resource = ResourceMgr.getInstance().find( "xxx"); if(resource == null) { return; } ///do business with resource}}

抽象一个接口类，find时返回接口IResource而非实现Resource对象。此时，成员变量的生命周期被放大，但对象的状态变更依旧在所属对象的控制之内。二者各有优缺点，到底使用哪种方案要根据具体使用场景而定。

上述两种方案都尝试解决控制成员变量的生命周期和状态变更的“可追踪性”，但如果我们期望的是更新符合find条件的对象，此时上述两种方案均不可取，而应在ResourceMgr中提供相应的接口，如下：

classResourceMgr{ privatestaticResourceMgr instance = newResourceMgr(); privateList<Resource> resources = newArrayList<>(); privateResourceMgr(){ } publicstaticResourceMgr getInstance(){ returninstance; } publicbooleanupdate(String name, intnum){ Resource resource = resources.stream().filter((r) -> { returnr.getName().equals(name); }).findFirst().orElse( null); if(resource == null) { returnfalse; } resource.setNum(num); returntrue; }}

成员变量的生命周期控制在函数内部，因为其生命周期本身较短，我们通常疏于管理，使得生命周期放大，可读性降低。

违规代码：

publicvoiddoSomething(List<Resource> resources, List<Device> devices){ intresourceChecksum = 0; intdeviceChecksum = 0; intresourceTotal = 0; intdeviceTotal = 0; intresourceAverage = 0; intdeviceAverage = 0; StringBuilder resourceStringBuilder = newStringBuilder(); StringBuilder deviceStringBuilder = newStringBuilder(); //计算resource的average、checksumfor(Resource resource : resources) { resourceStringBuilder.append(resource.getName()); resourceTotal += resource.getNum(); } resourceChecksum = resourceStringBuilder.toString().hashCode(); resourceAverage = resourceTotal / resources.size(); //计算device的average、checksumfor(Device device : devices) { deviceStringBuilder.append(device); deviceTotal += device.getNum(); } deviceChecksum = deviceStringBuilder.toString().hashCode(); deviceAverage = deviceTotal / devices.size(); doAnoterThing(resourceChecksum, resourceAverage, deviceChecksum, deviceAverage); }

上述代码将所有的变量声明定义在函数顶部，但和device相关的变量只有在计算device时才需要，生命周期被放大。针对这点，可以做如下修改：

publicvoiddoSomething(List<Resource> resources, List<Device> devices){ intresourceChecksum = 0; intresourceTotal = 0; intresourceAverage = 0; StringBuilder resourceStringBuilder = newStringBuilder(); //计算resource的average、checksumfor(Resource resource : resources) { resourceStringBuilder.append(resource.getName()); resourceTotal += resource.getNum(); } resourceChecksum = resourceStringBuilder.toString().hashCode(); resourceAverage = resourceTotal / resources.size(); intdeviceChecksum = 0; intdeviceTotal = 0; intdeviceAverage = 0; StringBuilder deviceStringBuilder = newStringBuilder(); //计算device的average、checksumfor(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变量。我们期望这些临时变量的生命周期进一步降低，如下：

publicvoiddoSomething(List<Resource> resources, List<Device> devices){ //计算resource的average、checksumintresourceChecksum = 0; intresourceAverage = 0; { inttotal = 0; StringBuilder stringBuilder = newStringBuilder(); for(Resource resource : resources) { stringBuilder.append(resource.getName()); total += resource.getNum(); } resourceChecksum = stringBuilder.toString().hashCode(); resourceAverage = total / resources.size(); } //计算device的average、checksumintdeviceChecksum = 0; intdeviceAverage = 0; { inttotal = 0; StringBuilder stringBuilder = newStringBuilder(); 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：针对扩展点编程

你愚弄了我一次，可耻的是你；但如果你愚弄了我两次，可耻的是我。

----《福尔摩斯：基本演绎法》

你愚弄了我一次，可耻的是你；但如果你愚弄了我两次，可耻的是我。

----《福尔摩斯：基本演绎法》

首先声明，这是一条附赠规约，不是说它不重要，而是因为以本文的篇幅，不可能讲通。针对扩展点编程是一个很大的话题，大到《设计模式》要花整本书来讲。本文只能提供一些指导建议，希望能有所帮助。

本节，我们讨论两个问题：什么是扩展点？以及如何针对扩展点编程？

• 什么是扩展点？ 扩展点也称之为变化点，指的是软件中频繁变化的那一部分。系统中哪部分需求最活跃，那这部分就是系统的扩展点的来源。将需求映射到现有的系统业务模型，需要修改的那部分代码就是扩展点实现。 最理想的效果是：整个系统框架为所有的扩展点都做了预留，后续需求开发只需要在预留的“slot”上完成，系统框架不需要做任何变更。要达到这个效果，我们就需要具备预知能力，预知系统的演进方向、潜在需求等等。 对未来准确预知是不可能的，所以不存在完美的架构。构造出持续演进的框架是有可能的，但依然非常困难，你需要具备如下能力：
• 业务建模的能力。首先，你要是一个业务专家。熟悉你所在行业，并能提炼出准确的业务模型。
• 基于功能、质量属性架构的能力。功能来源于用户需求，质量属性指的是性能、安全、可扩展性、可用性、一致性等等。很多质量属性是相互矛盾的，典型的如CAP理论。如何选择质量属性，在满足功能需求的同时，最大程度匹配系统的演进方向。
• 对扩展点的把控力。并不是所有的需求都会成为系统的扩展点，好的设计人员有能力评判断哪些需求能成为扩展点，而哪些不能。错失扩展点抽象，将会影响系统的稳定性；增加无谓的扩展点，将增加维护成本，不利于对整个系统的理解。
• 持续演进的能力。一个基于持续演进架构的、稳定的系统，其需求量和代码量之间不应该呈现出线性关系，而应类似下图： 需求-代码量曲线 其实，系统的扩展点也大致遵循上述原则。我们强调持续演进，时刻考虑推翻之前的部分架构设计，用更符合当前系统演进的架构替代，保持系统的生命力。 至于如何挖掘扩展点，建议参考《敏捷软件开发--原则、模式与实践》、《领域驱动设计》。
• 如何和针对扩展点编程？ 一旦你有能力识别扩展点，那么针对扩展点编程就变得很容易了。 针对扩展点编程最主要的一个指导原则：开放封闭原则(OCP)。OCP的标准定义为：针对修改封闭，针对扩展开放。用通俗的话来说，如果有一个新的需求，我们期望达到如下效果：现有代码一行不改(或极少改动)，在现有代码基础上通过增加新的类或配置的方式实现需求功能。 关于OCP原则，《敏捷软件开发--原则、模式与实践》的第九章有详细描述，本文不再赘述。另外，GOF的《设计模式》就是从实践中总结出来的、针对扩展点编程的具体方法，业界的经典之作。

• 业务建模的能力。首先，你要是一个业务专家。熟悉你所在行业，并能提炼出准确的业务模型。
• 基于功能、质量属性架构的能力。功能来源于用户需求，质量属性指的是性能、安全、可扩展性、可用性、一致性等等。很多质量属性是相互矛盾的，典型的如CAP理论。如何选择质量属性，在满足功能需求的同时，最大程度匹配系统的演进方向。
• 对扩展点的把控力。并不是所有的需求都会成为系统的扩展点，好的设计人员有能力评判断哪些需求能成为扩展点，而哪些不能。错失扩展点抽象，将会影响系统的稳定性；增加无谓的扩展点，将增加维护成本，不利于对整个系统的理解。
• 持续演进的能力。一个基于持续演进架构的、稳定的系统，其需求量和代码量之间不应该呈现出线性关系，而应类似下图： 需求-代码量曲线 其实，系统的扩展点也大致遵循上述原则。我们强调持续演进，时刻考虑推翻之前的部分架构设计，用更符合当前系统演进的架构替代，保持系统的生命力。 至于如何挖掘扩展点，建议参考《敏捷软件开发--原则、模式与实践》、《领域驱动设计》。

本文讲了6条基本编程规约、1条架构指导规约。我尝试以最少的文字描述，帮助一线开发人员提升编码能力，但最后文章的篇幅还是超出了我的预期。

同样，限于本文的篇幅，有太多的细节没有展开，好在有前辈早已帮我们整理成文。如本文最开始说的，如果你真正的想提高自身的编码、架构能力，请仔细翻阅以下书籍(建议按先后顺序阅读)：

(完)

作者：随安居士

链接：https://www.jianshu.com/p/1b8b378b0505

來源：简书返回搜狐，查看更多