软件腐化的七个特征之牢固性和粘滞性(设计模式原则的反面) (《敏捷软件开发》读书总结第二篇)


前言

最近读Robert C. Martin(Bob大叔)的书《敏捷软件开发》,准备围绕这本书开一个专题来写点读书总结。本文是这个专题的第二篇。

设计模式有六大原则:单一原则;里氏替换原则;依赖倒置原则;接口隔离原则;迪米特原则;开闭原则。软件腐化可以理解为是设计模式六大原则的对立面。

当软件出现以下七种特征之一时,就说明软件正在腐化:僵化性(Rigidity)、脆弱性(Fragility)、牢固性(Immobility)、粘滞性(Viscosity)、不必要的复杂性(Needless Complexity)、不必要的重复(Needless Repetition)、晦涩性(Opacity)。


牢固性(Immobility)

原文

设计中包含了对其他系统有用的部分,但是要把这些部分从系统中分离出来需要的努力和风险是巨大的。

我的理解

牢固性(Immobility)在实际做项目做开发时还是很常见的,这里我就不具体举例说明了。

大致列举几种我认为最常见的导致牢固性(Immobility)的场景:代码注释不足、代码中经常针对特殊情况开小灶(做特殊处理)、代码写的比较反人类(比如各种“与”、“或”、“非”逻辑运算的复杂排列组合)。


粘滞性(Viscosity)

原文

当面临一个改动时,开发人员常常会发现会有多种改动的方法。其中,一些会保持设计;而另外一些会 破坏设计(也就是生硬的手法) 。当那些可以保持系统设计的方法比那些生硬手法更难应用时,就表明设计具有高的粘滞性。做错误的事情是容易的,但是做正确的事情却很难。

我的理解

说起粘滞性(Viscosity),我们公司目前的项目在架构设计方面就遇到一个和粘滞性(Viscosity)有关的问题,下面我就
以此为例来聊聊。这个例子稍微有点复杂,得耐心一点看下去。

粗略的架构图:
在这里插入图片描述
为了便于后续描述,先详细介绍一下系统的总体架构思路:系统采用微服务架构的思想来进行业务拆分,分了四大系统(即四套WebAPI接口,也可以理解为四个服务):底层的核心数据系统(管理公用的核心数据)、底层的单点登录系统(管理用户相关数据)、上层的业务子系统1、上层的业务子系统2。核心数据系统负责共享核心数据,单点登录系统负责统一和共享各个业务系统的用户数据,而所有的实际业务都在业务子系统1或者业务子系统2里完成。这四大系统之间通过Web API(即Http接口)的形式来完成依赖(见图中虚线)。

有这样一个场景:在业务子系统1中有一个业务a(见图中标蓝字体),这个业务a需要同时拼接:业务子系统a自身的业务表a,单点登录系统里的用户表,核心数据系统里的核心数据表A。

正常情况下,我们在业务子系统1中会先通过Web API去访问单点登录系统里的用户表和核心数据系统里的核心数据表A,然后再从业务子系统1自身的数据库中获取业务表a,以完成拼接,整个拼接的过程在业务子系统a的业务代码中完成。这种拼接方式是符合这张架构图的设计初衷的——业务子系统1与单点登录系统或者核心数据系统的依赖关系全部都收敛在业务子系统1的业务代码中。

但是,上述的情况在实际操作中会出现两个难以解决的问题:1、在 业务子系统1的业务代码里完成表的拼接所需要编写的代码量很大,尤其是有时候涉及到分组(group by)代码会特别难以编写;2、在业务子系统1的业务代码里完成表的拼接需要借助Web API去依赖单点登录系统和核心数据系统,这样写出来的代码运行效率极其低下,因为每一次都需要把单点登录系统的用户表里的大块数据和核心数据系统的核心数据表A的大块数据全部取过来,加载到业务子系统1的业务代码的内存中进行下一步的拼接、分组、排序、筛选等操作。

于是,有同事想出来一个 破坏设计(也就是生硬的手法) 但是能解决上述两个问题的办法:

鉴于我们四大系统的各个数据库在实际部署时,都部署在同一台服务器,而且由同一个账号下的用户统一管理(数据库权限分配这一点本身是存在很大问题隐患的)。我们可以在业务子系统1的数据库下创建存储过程(数据库级别的业务代码),在这个存储过程里直接访问单点登录系统里的用户表和核心数据系统里的核心数据表A,以及自身的业务表a,完成拼接。(见下图)

在这里插入图片描述
这样一来,只需要在业务子系统1的业务代码里去调用该存储过程即可,所有业务逻辑都在存储过程里实现。这样做,既减少了工作量,又不用担心效率问题。但是这样做破坏了设计:业务子系统1对单点登录系统和核心数据系统的依赖不再仅仅是通过WebAPI,依赖关系不再收敛于 业务子系统1的业务代码 中了,这为后续系统的维护和扩展埋下很深的隐患。

在上述这个例子里,做错误的事情(破坏原有设计的事情)是容易的,做正确的事情(符合设计的事情)很难。原有的架构设计看似优美而且合理,但是落实的时候,由于业务代码拼接表时语法的有限性(相对于数据库自带SQL语法),以及在现有条件下Http通信效率不好等问题,原有架构设计就体现出很严重的粘滞性(Viscosity)。


  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值