vlambda博客
学习文章列表

凌云时刻

编者按：提升代码质量的方法，笔者喜欢用三个方法：领域建模、设计原则、设计模式，本文主要谈下如何使用。

影响代码差的根因

 差代码的体现

 问题归纳

• 命名问题： 命名问题是一件非常头疼的事，想要取一个名副其实又好理解的名字并不那么容易。涉及到变量的命名、方法的命名、类命名，常见的命名问题有两种：一种是不知所云；另一种是名不副实。命名不知所云是一个人初一看，不知道它是什么意思，根本原因就是没有想到一个合适的词汇去抽象问题；命名名不副实是命名和实际逻辑想表达的意思不一样，这样的命名会误导人。
• 代码结构问题： 当一个人初看工程代码时，当还没有深入看代码逻辑时，从模块划分、类划分、方法划分整体上可以感受得出代码质量，如果一个类有几千行代码，一个方法有几百行，这样的逻辑相信没有多少人愿意去看，复杂度比较高。好的代码层次结构非常清晰，就像看一本优美的书一样有一种赏心悦目的感觉。
• 编程范式问题： 有三种编程范式：表模式、事务脚本模式和领域设计模式，大家用得最多的是事务脚本模式，这种模式最符合人做事的方法，step by step，这种模式最大的问题就是承担了不该自己承担的职责，看起来比较符合逻辑，实际上问题比较多，平时大家喜欢称之为"面条型代码"。
• 可读性问题： 代码除了实现业务功能外，还要具备良好的可读性，有的代码没有任何注释；有的代码格式不统一；有的是为了炫耀技术，大段大段的Lambda表达式（并不是说Lambda表达式不好，关键要控制层次深度），这样的代码看起来简洁，可读性并不太好。
• 扩展性问题： 可扩展性问题是一个老生常谈的问题，要实现良好的可扩展性并不那么容易，一般是没有抽象问题，如店铺在店招头展示Tab，面条型的代码就是直接定义一个List，然后往里面加Tab对象，如果需要再加一个Tab怎么办？典型的就是不满足开闭原则。
• 无设计问题： 整个代码看起来比较平淡，别人看了之后也从中学习不到内容。一般这种问题是没有深入分析问题，仅仅解决了问题，而没有考虑如何更好地解决问题，比如重复处理流程的工作是否可以抽象成一个通用的模板类、不同处理类是否可以通过工厂类去获取具体的策略、异步处理是否可以使用事件模式去处理、对于新增加的能力能否通过自动注册去发现……

 根因分析

提升代码质量的方法

提升代码质量的方法，作者喜欢用三个方法：领域建模、设计原则、设计模式，主要谈下如何使用：

• 分析阶段：当拿到一个需求时，先不要着急想着怎么把这个功能实现，这种很容易陷入事务脚本的模式。分析什么呢？需要分析需求的目的是什么、完成该功能需要哪些实体承担，这一步核心是找实体。举个上面进店Tab展示的例子，它有两个关键的实体：导航栏、Tab，其中导航栏里面包含了若干个Tab。

• 设计阶段：分析完了有哪些实体后，再分析职责如何分配到具体的实体上，这就要运用一些设计原则去指导，GRASP中提到一些职责分配的原则，感兴趣的同学可以去详细看看。回到上面的例子上，Tab的职责主要有两个：一个是Tab能否展示，这是它自己的职责，如上新Tab展示的逻辑是店铺30天内有上架新商品；另一个职责就是Tab规格信息的构建，也是它自己要负责的。导航栏的职责有两个：一个是接受Tab注册；另一个是展示。职责分配不适理，也就不满足高内聚、低耦合的特征。

• 打磨阶段：这个阶段选择合适的模式去实现，大家一看到模式都会理解它是做什么的，比如看到模板类，就会知道处理通用的业务流程，具体变化的部分放在子类中处理。上面的这个例子，用到了2个设计模式：一个是订阅者模式，Tab自动注册的过程；另一个是模板模式，先判断Tab能否展示，然后再构建Tab规格信息，流程虽然简单，也可以抽象出来通用的流程出来，子类只用简单地重写2个方法。

领域模型的作用

领域建模的入门门槛比较高，包含了一些难理解的概念。本篇文章中并不会讲述如何进行建模（可以私下交流），笔者发现让大家接受领域建模远比知道如何建模更重要，当你知道了领域建模的作用后，自己会想各种办法去学习。下面通过笔者经历的一些实际案例进行阐述，让大家听起来并不感觉到那么空洞。

 简化认识

笔者工作一年后加入到了一家金融公司，当时对金融一无所知，开始接触到标的、债权、债权转让、融资担保、非融资担保等名词后，一时感到无所适从，每天要学习非常多的新内容。

两个月后，我的主管给我们做了一次分享，就拿了一张ppt来讲，它里面包含了领域的实体，以及实体之间的关联关系，一下子我就知道了整个业务是怎么玩转的。模型的作用就是简化人对事物的认识，如果一开始我们就陷入到代码细节中，很难看到业务的全貌，而且代码是为了实现业务能力，当你知道了业务之后，再去看代码就会快得多。

 统一认识

在公司里，有研发、产品、运营、测试……，当我们在一起交流的时候，大家默认的语言是不统一的，开发经常讲怎么操作这张数据库表，产品经常讲业务模式……这就导致大家的认识并不统一。

那是一个晚上，刚和交互同学确认完交互流程后，突然她问了一个问题：把相似的页面让卖家移到同一个文夹中，这个好实现吧？听完后告知不能，交互同学一听说这很合理呀，怎么实现不了？开始给她讲了下现有的系统流程，发现她听得一脸懵逼，马上发现问题了，我是用开发的语言在描述问题，立马换了一种方式，找了一支笔和一张纸，给交互同学画了我们的领域模型是什么，业务实体之间的交互是怎样的，一讲完后，交互同学马上明白了为什么不能实现的原因所在了。

 指导设计

有的同学觉得领域建模偏空洞，比较虚，其实除了能够简化认识和统一认识外，领域建模还可能指导代码设计，比如上面举的店铺导航Tab的例子，笔者就是通过领域建模来设计的，虽然它是一个小的需求，并不妨碍领域建模的运用。

在下图中，可以清晰的看到，导航栏包含了若干个Tab，一个Tab包含规格信息和点击操作信息。把这个业务模式画出来之后，对应的代码中也会有上面的概念，现实与代码之间存在映射关系，模型即代码，代码即模型。如果你的模型不能反映现实，模块只能算是一个花架子，范钢老师对此总结了三句话：现实有什么事物，对应有什么对象；现实事物有什么行为，对应对象有什么方法；现实事物有什么联系，对应对象有什么关联。

设计原则的底层逻辑

 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，抽象不依赖于细节，而细节依赖于抽象。

 为什么要有设计原则

 如何落地实践

设计模式的本质

案例实践

 店铺品牌查询

 店铺优惠券查询