业务代码如何才能不再写出大串的if/else?(上)

简介: 业务代码如何才能不再写出大串的if/else?

控制结构?没错!你最爱的 if、for都是一类坏味道,没想到吧?自己竟然每天都沉浸在写坏味道的体验中。

控制语句,到底何错之有呢?

嵌套代码

CR 如下分发我刚写完的一篇博客的案例:

image.png

逻辑很简单,但有多层缩进,for 循环一层,里面有俩 if ,又多加两层。若逻辑再复杂点,缩进岂不是像啤酒肚一般越来越大?


为啥代码会写成这鬼样子呢?


因为你在写流水账,如机器人般地按需求一步步翻译成代码。

代码逻辑肯定没错,但功能实现后,未重新整理代码。


现在就得消除缩进。


从for循环入手,通常for循环处理集合,而循环里处理的是该集合中的元素。所以,可将循环中的内容提取成方法,只处理一个元素:

1.png

这就是一次拆分,分解出来事务 issueArticle 每次只处理一个元素。这就优化了缩进问题:

  • issueArticles 只有一层缩进,这才是正常方法应有的样子
  • 但 issueArticle 还残留多层缩进,待继续优化

if 和 else

issueArticle 里,造成缩进的原因是 if 语句。if 缩进很多时候都是在检查某先决条件,条件通过时,才能执行后续代码。

这样的代码可使用卫语句(guard clause),即设置单独检查条件,不满足该检查条件时,方法立刻返回。

以卫语句取代嵌套的条件表达式(Replace Nested Conditional with Guard Clauses)。

重构后的 issueArticle 函数:

1.png

如今这就只剩一层缩进,代码复杂度大大降低,可读性和可维护性也大大增强。

禁用else

大多数人印象中,if 和 else 几乎比翼齐飞。

else 可以不写吗?

可以!

根据文章信息进行收费:

image.png

不用 else,简单方式就是让每个逻辑提前返回,类似卫语句:

image.png

业务简单的代码,这重构还很轻松,但对复杂代码,就得上多态了。


嵌套、else 语句,都是坏味道,本质上都在追求简单,因为一段代码的分支过多,其复杂度就会大幅度增加。


衡量代码复杂度常用的标准,圈复杂度(Cyclomatic complexity,CC),CC越高,代码越复杂,理解和维护的成本越高。

在CC判定中,循环和选择语句占主要地位。CC可使用工具检查,如Checkstyle,可限制最大的圈复杂度,当圈复杂度大于设定阈值,就报错。

重复 Switch

1.png

实际支付的价格会根据用户在系统中的用户级别有所差异,级别越高,折扣越高。


两个函数里出现了类似的代码,其中最类似部分就是 switch,都据用户级别判断。

这并非仅有的根据用户级别进行判断的代码,各种需区分用户级别场景都有类似代码,而这也是一种典型的坏味道:重复switch(Repeated Switch),通常都是因为缺少一个模型。

解决方案:以多态取代条件表达式(Relace Conditional with Polymorphism)。




目录
相关文章
|
测试技术
|
6月前
|
算法 开发者
如何从写业务代码中跳出来,有效提升个人技术能力?
如何从写业务代码中跳出来,有效提升个人技术能力?
|
11月前
「业务架构」定义业务能力-备忘单
「业务架构」定义业务能力-备忘单
|
11月前
|
运维 监控 NoSQL
浅谈业务开发与非业务开发
讲述业务开发、非业务开发及两者之间区别
|
12月前
|
运维 JavaScript 安全
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
93 0
|
SQL JSON 关系型数据库
组件测试-复杂业务系统的单测解决方案
本文的目的长久以来,码农们有一种默契的共识,只有写的好的代码才能写单测,代码的可测性也因此成为了评判好代码的一个标准。但是,同学有没有想过,我们手里有多少是写的好的代码,很多情况下,我们接手的代码都是又长又臭的“面条代码”,难道我们就不能对这些应用写单测了吗?难道这些应用不是更需要单测的保障吗?在本文中,我将使用一种全新的单测解决方案,通过这个方案,再复杂的应用也能简单的实现单测覆盖,保障我们的业
组件测试-复杂业务系统的单测解决方案
|
项目管理 数据安全/隐私保护
【平台开发】— 7.重构-增加结果统一处理
【平台开发】— 7.重构-增加结果统一处理
【平台开发】— 7.重构-增加结果统一处理
|
存储 SQL 数据可视化
模板化的封装,降低业务代码开发
做这些业务设计时,核心思想是:把常用的逻辑进行封装,流程设计为可配置,这样即可在一定时间内应对业务的需求和变化,降低开发成本的支出,从而使研发更侧重核心业务的管理和抽象封装等内容。
124 0
模板化的封装,降低业务代码开发
|
前端开发 Java 程序员
业务代码与技术代码
当程序员大多都有一个共同的经历:当你在改一段复杂的代码时,你一边吐槽是哪个小可爱写的这段像一坨*一样的代码时,一边打开了提交记录,赫然发现竟然是自己3个月前写的!
2994 0
带你进入业务分析、设计领域
带你进入业务分析、设计领域 本文通过介绍几本对我印象比较深刻的书籍,来让学习业务分析、设计领域更加容易些(加快找到分析感觉)。 起航 要介绍的第一本应该是比较基础,且跟业务领域比较接近的,我选择《对象模型 策略 模式 应用》。
1309 0