共计 5031 个字符，预计需要花费 13 分钟才能阅读完成。
简介：晋升代码品质的三个无效办法：领域建模、设计准则、设计模式。
影响代码差的根因
差代码的体现
咱们能够列举出十分多品质差的代码的体现景象，如名字不知所意、超大类、超大办法、反复代码、代码难懂、代码批改艰难……其中最为影响代码品质的两个体现是命名徒有虚名、逻辑可扩展性差，当一个新人浏览代码时，有时发现办法命名与理论逻辑对不上，这就让人感到十分纳闷，这种景象在平时工作并不少见；另一个就是逻辑扩展性差，一个新业务需要提出来后，发现要在多处改变，须要回归的业务逻辑比拟多，造成研发效率不高。
问题演绎
对前文提到的景象进行问题演绎整顿，大抵整顿出 6 类问题，别离开展加以阐明。
命名问题：命名问题是一件十分头疼的事，想要取一个货真价实又好了解的名字并不那么容易。波及到变量的命名、办法的命名、类命名，常见的命名问题有两种：一种是不知所云；另一种是徒有虚名。命名不知所云是一个人初一看，不晓得它是什么意思，根本原因就是没有想到一个适合的词汇去形象问题；命名徒有虚名是命名和理论逻辑想表白的意思不一样，这样的命名会误导人。
代码构造问题：当一个人初看工程代码时，当还没有深刻看代码逻辑时，从模块划分、类划分、办法划分整体上能够感触得出代码品质，如果一个类有几千行代码，一个办法有几百行，这样的逻辑置信没有多少人违心去看，复杂度比拟高。好的代码层次结构十分清晰，就像看一本柔美的书一样有一种赏心悦目的感觉。
编程范式问题：有三种编程范式：表模式、事务脚本模式和畛域设计模式，大家用得最多的是事务脚本模式，这种模式最合乎人做事的办法，step by step，这种模式最大的问题就是承当了不该本人承当的职责，看起来比拟合乎逻辑，实际上问题比拟多，平时大家喜爱称之为 “ 面条型代码 ”。
可读性问题：代码除了实现业务性能外，还要具备良好的可读性，有的代码没有任何正文；有的代码格局不对立；有的是为了夸耀技术，大段大段的 Lambda 表达式（并不是说 Lambda 表达式不好，要害要管制档次深度），这样的代码看起来简洁，可读性并不太好。
扩展性问题：可扩展性问题是一个陈词滥调的问题，要实现良好的可扩展性并不那么容易，个别是没有形象问题，如店铺在店招头展现 Tab，面条型的代码就是间接定义一个 List，而后往里面加 Tab 对象，如果须要再加一个 Tab 怎么办？典型的就是不满足开闭准则。
无设计问题：整个代码看起来比拟平淡，他人看了之后也从中学习不到内容。个别这种问题是没有深入分析问题，仅仅解决了问题，而没有思考如何更好地解决问题，比方反复解决流程的工作是否能够形象成一个通用的模板类、不同解决类是否能够通过工厂类去获取具体的策略、异步解决是否能够应用事件模式去解决、对于新减少的能力是否通过主动注册去发现……
根因剖析
接下来剖析下为什么会产生代码差的起因，这个问题有内部起因，也有外部起因。
内部起因次要有：我的项目排期急，没有多少工夫去设计；资源短缺，人手不够，只能怎么快怎么来；紧急问题修复，长期计划疾速解决……。
外部起因次要有：本身技能低，怎么技能没有把握到，如 Lamda 表达式、罕用的工具类、框架高级用法等；无极致谋求的精力，仅仅实现需要就行，稳定性、可扩展性、性能、数据一致性等没有思考……
笔者认为最为要害的是外部本身的问题，根因就两个：自我要求不高；无反馈通道。如果对自已要求不高，仅仅满足实现需要开发就止步了，很难写出高质量的代码，另外如果没有内部反馈，也难以进步本人的技能。笔者之前的主管十分严格，对大家写的代码 review 比拟认真，一个变量名、一段逻辑的写法，重复让批改，这其实是晋升技能最快的办法。
晋升代码品质的办法
晋升代码品质的办法，作者喜爱用三个办法：领域建模、设计准则、设计模式，次要谈下如何应用：
分析阶段：当拿到一个需要时，先不要焦急想着怎么把这个性能实现，这种很容易陷入事务脚本的模式。剖析什么呢？须要剖析需要的目标是什么、实现该性能须要哪些实体承当，这一步外围是找实体。举个下面进店 Tab 展现的例子，它有两个要害的实体：导航栏、Tab，其中导航栏外面蕴含了若干个 Tab。
设计阶段：剖析完了有哪些实体后，再剖析职责如何调配到具体的实体上，这就要使用一些设计准则去领导，GRASP 中提到一些职责调配的准则，感兴趣的同学能够去具体看看。回到下面的例子上，Tab 的职责次要有两个：一个是 Tab 是否展现，这是它本人的职责，如上新 Tab 展现的逻辑是店铺 30 天内有上架新商品；另一个职责就是 Tab 规格信息的构建，也是它本人要负责的。导航栏的职责有两个：一个是承受 Tab 注册；另一个是展现。职责调配不适理，也就不满足高内聚、低耦合的特色。
打磨阶段：这个阶段抉择适合的模式去实现，大家一看到模式都会了解它是做什么的，比方看到模板类，就会晓得解决通用的业务流程，具体变动的局部放在子类中解决。下面的这个例子，用到了 2 个设计模式：一个是订阅者模式，Tab 主动注册的过程；另一个是模板模式，先判断 Tab 是否展现，而后再构建 Tab 规格信息，流程尽管简略，也能够形象进去通用的流程进去，子类只用简略地重写 2 个办法。
畛域模型的作用
领域建模的入门门槛比拟高，蕴含了一些难了解的概念。本篇文章中并不会讲述如何进行建模（能够私下交换），笔者发现让大家承受领域建模远比晓得如何建模更重要，当你晓得了领域建模的作用后，本人会想各种方法去学习。上面通过笔者经验的一些理论案例进行论述，让大家听起来并不感觉到那么空洞。
简化意识
笔者工作一年后退出到了一家金融公司，过后对金融无所不知，开始接触到标的、债务、债务转让、融资担保、非融资担保等名词后，一时感到莫衷一是，每天要学习十分多的新内容。
两个月后，我的主管给咱们做了一次分享，就拿了一张 ppt 来讲，它外面蕴含了畛域的实体，以及实体之间的关联关系，一下子我就晓得了整个业务是怎么玩转的。模型的作用就是简化人对事物的意识，如果一开始咱们就陷入到代码细节中，很难看到业务的全貌，而且代码是为了实现业务能力，当你晓得了业务之后，再去看代码就会快得多。
统一认识
在公司里，有研发、产品、经营、测试……，当咱们在一起交换的时候，大家默认的语言是不对立的，开发常常讲怎么操作这张数据库表，产品常常讲业务模式……这就导致大家的意识并不对立。
那是一个早晨，刚和交互同学确认完交互流程后，忽然她问了一个问题：把类似的页面让卖家移到同一个文夹中，这个好实现吧？听完后告知不能，交互同学一据说这很正当呀，怎么实现不了？开始给她讲了下现有的零碎流程，发现她听得一脸懵，我立即意识到，我是用开发的语言在形容问题，立马换了一种形式，找了一支笔和一张纸，给交互同学画了咱们的畛域模型是什么，业务实体之间的交互是怎么的，一讲完后，交互同学马上明确了为什么不能实现的起因所在了。
领导设计
有的同学感觉领域建模偏空洞，比拟虚，其实除了可能简化意识和统一认识外，领域建模还可能领导代码设计，比方下面举的店铺导航 Tab 的例子，笔者就是通过领域建模来设计的，尽管它是一个小的需要，并不障碍领域建模的使用。
在下图中，能够清晰的看到，导航栏蕴含了若干个 Tab，一个 Tab 蕴含规格信息和点击操作信息。把这个业务模式画进去之后，对应的代码中也会有下面的概念，事实与代码之间存在映射关系，模型即代码，代码即模型。如果你的模型不能反映事实，模块只能算是一个花架子，范钢老师对此总结了三句话：事实有什么事物，对应有什么对象；事实事物有什么行为，对应对象有什么办法；事实事物有什么分割，对应对象有什么关联。
设计准则的底层逻辑
SOLID
对于设计准则，个别咱们谈判到 SOLID，它蕴含了五个设计准则：
- 繁多职责准则：A class should have one, and only one, reason to change，一个类只能因为一个理由被批改。
- 开闭准则：Entities should be open for extension, but closed for modification，对扩大凋谢，对批改敞开。
- 里氏替换准则：Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it，子类能够替换父类。
- 接口隔离准则：A client should not be forced to implement an interface that it doesn’t use，不能强制客户端实现它不应用的接口，应该把接口拆的尽可能小。
- 依赖倒置准则：Abstractions should not depend on details. Details should depend on abstractions，形象不依赖于细节，而细节依赖于形象。
为什么要有设计准则
咱们对 SOLID 准则基本上据说过或者理解过，但为什么要有这些设计准则呢？为了答复这个问题，咱们从指标往下推导下。软件开发的指标是高内聚、低耦合，这句挂在嘴边的话，发现很难掂量，比方要答复：什么样的叫高内聚？什么样的叫低耦合？高内聚要高到什么水平？低耦合要低到什么水平？这四个问题并不太好答复。
反过来想想，如果咱们的代码不是高内聚和低耦合的会怎么？也即是低内聚和高耦合的场景。如果代码是低内聚和高耦合，则会呈现批改一个逻辑，会导致多处代码要批改，这个并不是咱们心愿看到的，尤其在批改原有的逻辑，很容易呈现 bug，比方笔者之前批改一个问题，改了另外一处的规定，看起来是没有问题，后果影响到了一个业务方，这也是为什么开闭准则提出对批改敞开的起因，批改原有的逻辑是有危险的。
现实的状况是批改只限定在某个部分范畴内，这样影响的范畴无限，因而咱们要求逻辑要繁多，不要蕴含多个职责。再往下思考下：为什么咱们要批改呢？除了原有逻辑有 bug 要修复、代码重构外，一个重要的起因是需要产生了变动，是变动导致咱们要对原有的逻辑进行批改。如果没有批改的场景，也就没有所谓的高内聚、低耦合之说了。因而设计准则的底层逻辑就是让软件可能较好地应答变动，降本增效。
如何落地实际
设计准则只是一个领导的方针，离落地实际还有很大的一段距离，就像有些同学说设计准则我懂了，但我仍然使用不到。实际上这个问题的实质还是对设计准则的底层逻辑没有了解，没有洞察出变动关注点，怎么解决这个问题呢？设计模式给出的答案：找到变动、封装变动。
设计模式的实质
案例实际
当调用的接口有不同的实现时（入参、出参、接口都不雷同），须要形象出一层防腐层，怎么去实现呢？接下来别离看 2 个案例，这 2 个案例的侧重点不一样，一个是偏行为的形象，一个是偏构造的形象。
店铺品牌查问
店铺须要查问店铺品牌信息，然而 Lazada 和 AE 的接口是不一样的，怎么形象防腐层呢？
首先最简略的计划很容易想到，就是定义一个接口，而后有两个实现。它的长处是档次简略，大家根本看了就懂。它的毛病也是显著的，在两个实现类中，职责不一繁多，承当了两个职责：一个是实现店铺品牌的查问，另一个是数据转换。
依据计划一提到的毛病，很容易想到应用适配器模式，将之前的类拆成两个类：一个类是调用对应的品牌服务；另一个类做数据适配转换。不过此时的形式还有一个毛病就是在国际化场景下，要思考多租户之间的隔离，比方 Lazada 有多个站点，如何实现更细粒度的差别呢？计划三基于这些的思考就产生了。
计划三是引入了多租户框架，可能撑持多租户场景。
店铺优惠券查问
有一种 ” 万金油 ” 式开发模式：组装参数、调用接口、解析响应后果，你会发现这种模式太万能了，适宜所有的场景，这样的开发模式也即是 ” 事务脚本模式 ” 或者 ” 面条型代码 ”。
优惠券查问的案例，用领域建模的模式，首先思考有哪些实体。优惠券查问的实质：通过 xx 条件查问返回满足条件的优惠券汇合。对于优惠券来讲，有两类信息至关重要。一个是优惠券的规格信息，如优惠券名称、优惠金额、有效期等；另一个是优惠券的限度条件。在查问的时候，是查店铺优惠券，还是查粉丝优惠券，或者是查问商品优惠券……。因而离开两局部形象优惠券：一个是优惠券查问申请；另一个是优惠券规格实体。
如果依照这样的设计，有一个毛病是业务方了解复杂度会回升，它是偏底层实现，没有做到应用简略。优惠券偏产品交付而非仅仅性能交付。因而在底层实现之上，再形象出产品组件，这样业务方应用起来就比较简单。
原文链接
本文为阿里云原创内容，未经容许不得转载。
