提升代码质量的方法:领域模型、设计原则、设计模式-阿里云开发者社区

开发者社区> 开发者小助手_LS> 正文

提升代码质量的方法:领域模型、设计原则、设计模式

简介: 我们可以列举出非常多质量差的代码的表现现象,其中最影响代码质量的两个表现是命名名不副实、逻辑可扩展性差,当一个新人阅读代码时,有时发现方法命名与实际逻辑对不上,这就让人感到非常疑惑,这种现象在平时工作并不少见;另一个就是逻辑扩展性差,一个新业务需求提出来后,发现要在多处改动,需要回归的业务逻辑比较多,造成研发效率不高。
+关注继续查看

image.png

作者 | 不拔
来源 | 阿里技术公众号

一 影响代码差的根因

1 差代码的体现

我们可以列举出非常多质量差的代码的表现现象,如名字不知所意、超大类、超大方法、重复代码、代码难懂、代码修改困难……其中最为影响代码质量的两个表现是命名名不副实、逻辑可扩展性差,当一个新人阅读代码时,有时发现方法命名与实际逻辑对不上,这就让人感到非常疑惑,这种现象在平时工作并不少见;另一个就是逻辑扩展性差,一个新业务需求提出来后,发现要在多处改动,需要回归的业务逻辑比较多,造成研发效率不高。

2 问题归纳

对第1节中提到的现象进行问题归纳整理,大致整理出6类问题,分别展开加以说明。

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

3 根因分析

接下来分析下为什么会产生代码差的原因,这个问题有外部原因,也有内部原因。外部原因主要有:项目排期急,没有多少时间去设计;资源短缺,人手不够,只能怎么快怎么来;紧急问题修复,临时方案快速处理……。内部原因主要有:自身技能低,怎么技能没有掌握到,如Lamda表达式、常用的工具类、框架高级用法等;无极致追求的精神,仅仅完成需求就行,稳定性、可扩展性、性能、数据一致性等没有考虑……

笔者认为最为关键的是内部自身的问题,根因就两个:自我要求不高;无反馈通道。如果对自已要求不高,仅仅满足完成需求开发就止步了,很难写出高质量的代码,另外如果没有外部反馈,也难以提高自己的技能。笔者之前的主管非常严厉,对大家写的代码review比较仔细,一个变量名、一段逻辑的写法,反复让修改,这其实是提升技能最快的方法。

image.png

二 提升代码质量的方法

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

  • 分析阶段:当拿到一个需求时,先不要着急想着怎么把这个功能实现,这种很容易陷入事务脚本的模式。分析什么呢?需要分析需求的目的是什么、完成该功能需要哪些实体承担,这一步核心是找实体。举个上面进店Tab展示的例子,它有两个关键的实体:导航栏、Tab,其中导航栏里面包含了若干个Tab。
  • 设计阶段:分析完了有哪些实体后,再分析职责如何分配到具体的实体上,这就要运用一些设计原则去指导,GRASP中提到一些职责分配的原则,感兴趣的同学可以去详细看看。回到上面的例子上,Tab的职责主要有两个:一个是Tab能否展示,这是它自己的职责,如上新Tab展示的逻辑是店铺30天内有上架新商品;另一个职责就是Tab规格信息的构建,也是它自己要负责的。导航栏的职责有两个:一个是接受Tab注册;另一个是展示。职责分配不适理,也就不满足高内聚、低耦合的特征。
  • 打磨阶段:这个阶段选择合适的模式去实现,大家一看到模式都会理解它是做什么的,比如看到模板类,就会知道处理通用的业务流程,具体变化的部分放在子类中处理。上面的这个例子,用到了2个设计模式:一个是订阅者模式,Tab自动注册的过程;另一个是模板模式,先判断Tab能否展示,然后再构建Tab规格信息,流程虽然简单,也可以抽象出来通用的流程出来,子类只用简单地重写2个方法。

image.png

三 领域模型的作用

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

1 简化认识

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

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

2 统一认识

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

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

3 指导设计

有的同学觉得领域建模偏空洞,比较虚,其实除了能够简化认识和统一认识外,领域建模还可能指导代码设计,比如上面举的店铺导航Tab的例子,笔者就是通过领域建模来设计的,虽然它是一个小的需求,并不妨碍领域建模的运用。在下图中,可以清晰的看到,导航栏包含了若干个Tab,一个Tab包含规格信息和点击操作信息。把这个业务模式画出来之后,对应的代码中也会有上面的概念,现实与代码之间存在映射关系,模型即代码,代码即模型。如果你的模型不能反映现实,模块只能算是一个花架子,范钢老师对此总结了三句话:现实有什么事物,对应有什么对象;现实事物有什么行为,对应对象有什么方法;现实事物有什么联系,对应对象有什么关联。

image.png

四 设计原则的底层逻辑

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

2 为什么要有设计原则

我们对SOLID原则基本上听说过或者了解过,但为什么要有这些设计原则呢?为了回答这个问题,我们从目标往下推导下。软件开发的目标是高内聚、低耦合,这句挂在嘴边的话,发现很难衡量,比如要回答:什么样的叫高内聚?什么样的叫低耦合?高内聚要高到什么程度?低耦合要低到什么程度?这四个问题并不太好回答。

反过来想想,如果我们的代码不是高内聚和低耦合的会怎样?也即是低内聚和高耦合的场景。如果代码是低内聚和高耦合,则会出现修改一个逻辑,会导致多处代码要修改,这个并不是我们希望看到的,尤其在修改原有的逻辑,很容易出现bug,比如笔者之前修改一个问题,改了另外一处的规则,看起来是没有问题,结果影响到了一个业务方,这也是为什么开闭原则提出对修改关闭的原因,修改原有的逻辑是有风险的。

理想的情况是修改只限定在某个局部范围内,这样影响的范围有限,因此我们要求逻辑要单一,不要包含多个职责。再往下思考下:为什么我们要修改呢?除了原有逻辑有bug要修复、代码重构外,一个重要的原因是需求发生了变化,是变化导致我们要对原有的逻辑进行修改。如果没有修改的场景,也就没有所谓的高内聚、低耦合之说了。因此设计原则的底层逻辑就是让软件能够较好地应对变化,降本增效。

3 如何落地实践

设计原则只是一个指导的方针,离落地实践还有很大的一段距离,就像有些同学说设计原则我懂了,但我依然运用不到。实际上这个问题的本质还是对设计原则的底层逻辑没有理解,没有洞察出变化关注点,怎么解决这个问题呢?设计模式给出的答案:找到变化、封装变化。

image.png

五 设计模式的本质

设计模式请参考笔者之前写的文章。

image.png

六 案例实践

当调用的接口有不同的实现时(入参、出参、接口都不相同),需要抽象出一层防腐层,怎么去实现呢?接下来分别看2个案例,这2个案例的侧重点不一样,一个是偏行为的抽象,一个是偏结构的抽象。

1 店铺品牌查询

店铺需要查询店铺品牌信息,然而Lazada和AE的接口是不一样的,怎么抽象防腐层呢?

首先最简单的方案很容易想到,就是定义一个接口,然后有两个实现。它的优点是层次简单,大家基本看了就懂。它的缺点也是明显的,在两个实现类中,职责不一单一,承担了两个职责:一个是实现店铺品牌的查询,另一个是数据转换。

根据方案一提到的缺点,很容易想到使用适配器模式,将之前的类拆成两个类:一个类是调用对应的品牌服务;另一个类做数据适配转换。不过此时的方式还有一个缺点就是在国际化场景下,要考虑多租户之间的隔离,比如Lazada有多个站点,如何实现更细粒度的差异呢?方案三基于这些的思考就产生了。

方案三是引入了多租户框架,能够支撑多租户场景。

image.png

2 店铺优惠券查询

有一种"万金油"式开发模式:组装参数、调用接口、解析响应结果,你会发现这种模式太万能了,适合所有的场景,这样的开发模式也即是"事务脚本模式"或者"面条型代码"。

优惠券查询的案例,用领域建模的模式,首先思考有哪些实体。优惠券查询的本质:通过xx条件查询返回满足条件的优惠券集合。对于优惠券来讲,有两类信息至关重要。一个是优惠券的规格信息,如优惠券名称、优惠金额、有效期等;另一个是优惠券的限制条件。在查询的时候,是查店铺优惠券,还是查粉丝优惠券,或者是查询商品优惠券……。因此分开两部分抽象优惠券:一个是优惠券查询请求;另一个是优惠券规格实体。

如果按照这样的设计,有一个缺点是业务方理解复杂度会上升,它是偏底层实现,没有做到使用简单。优惠券偏产品交付而非仅仅功能交付。因此在底层实现之上,再抽象出产品组件,这样业务方使用起来就比较简单。

image.png

招聘

我们是国际化中台事业部-创新业务团队,基于国际化中台过去多年的沉淀,创新孵化全球化业务新赛道,团队的创新业务包含如下两个方向:

1、货通天下:基于中国产业链优势,通过打通阿里集团以及国内线下工厂货源,实现全球商品数字化,借助货通全球铺货和履约能力,实现商品全球卖;

2、商家SaaS:面向阿里大商家体系(商家,供应商,分销商等),打造一体化的商家经营SaaS产品,助力商家业务出海,以及多平台经营。

新业务、新赛道、新机遇,现在招后端Java方向,有意详聊:fulai.gfl@alibaba-inc.com


【公开课】手把手基于阿里云 ACK 环境创建 Kubernetes 集群及部署应用

本节课程阿里巴巴技术专家孙建波(天元)将为您介绍 5步上手K8s 中的 第1步——如何创建集群、部署应用。课程从介绍集群部署的三大常用方法开始、到手把手带您创建一个集群,再到手把手教您部署应用,环环相扣。相信通过本节课程的学习,您将能够使用 K8s 快速创建集群及部署应用。

点击这里,直通公开课~

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
25个JavaScript数组方法代码示例
摘要: 通过代码掌握数组方法。 原文:通过实现25个数组方法来理解及高效使用数组方法(长文,建议收藏) 译者:前端小智 Fundebug经授权转载,版权归原作者所有。 要在给定数组上使用方法,只需要通过[].方法名即可,这些方法都定义在 Array.prototype 对象上。
3408 0
23、Python与设计模式--设计原则
#一、六大设计原则 在法理学中,法律规则与法律原则都是法律规范的重要构成。但二者也会有些不同:法律规则是指采取一定的结构形式具体规定人们的法律权利、法律义务以及相应的法律后果的行为规范,内容比较明确,比如,交通法规中规定,禁止闯红灯;法律原则是指在一定法律体系中作为法律规则的指导思想,基本或本原的、综合的、稳定的原理和准则,内容上只包含“大方针”,而并未有具体规则,比如,如果车上有马上临产的孕妇
3039 0
Node.js SDK 使用方法及代码示例
本文介绍了如何使用阿里云视觉智能开放平台相关服务的Node.js SDK,具体包括SDK的获取和安装方法以及SDK代码示例。
297 0
设计模式6大原则
设计模式六大原则 开闭原则 开闭原则,是说对于软件实体(类、模块、函数等等)应该可以拓展,但是不可修改 这句话有两个意思,对于拓展是开放的,对于更改是封闭的。
1564 0
设计模式之八(原型模式)
原文:设计模式之八(原型模式) 前言 原型模式:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 结构图 Prototype,原型类,声明一个克隆自身的接口 ConcretePrototype1,ConcretePrototype2具体原型类,实现一个克隆自身的操作 Client,调用,让一个原型克隆自身从而创建一个新的对象 其实原型模式就是从一个对象再创建另外一个可定制的对象,而且不需知道任何创建的细节。
777 0
Windows下CMD中文乱码问题解决方法,设置代码页65001后仍然乱码
原文地址: http://blog.csdn.net/u011250882/article/details/48136883 在中文Windows系统中,如果一个文本文件是UTF-8编码的,那么在CMD.exe命令行窗口(所谓的DOS窗口)中不能正确显示文件中的内容。在默认情况下,命令行窗口中使用的代码页是中文或者美国的,即编码是中文字符集或者西文字符集。  如果想正确显示UTF-8
6629 0
Ruby入门(3)——方法、代码段
Ruby中的方法是一个有名称的代码块,是与一个或多个对象关联的参数化的代码。调用时须给出方法名,接收者(所在对象),参数值,且最后一个表达式的值做为返回值。与Ruby方法相似的是代码块,它没有名字,且调用时只通过迭代器或被间接调用。
637 0
283
文章
969
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载