关于系统:系统困境与软件复杂度为什么我们的系统会如此复杂

31次阅读

共计 10360 个字符，预计需要花费 26 分钟才能阅读完成。

作者：聂晓龙（率鸽）

读 A Philosophy of Software Design 有感，软件设计与架构复杂度，你是战术龙卷风吗？

前言

有一天，一个医生和一个土木工程师在一起争执“谁是世界上最古老的职业”。医生说：“上帝用亚当的肋骨造出了夏娃，这是历史上第一次外科手术，所以最古老的职业应该是医生”，土木工程师说：“在创世纪之前，上帝从混沌中发明了地狱与世间，这是更早之前的一次土木作业，所以最古老的职业应该是土木工程”。这时软件工程师拖着键盘走出来说，“那你认为，是谁发明了那片混沌？”

建筑师不会轻易给 100 层的高楼减少一个地下室，但咱们却常常在干这样的事，并且总有人会对你说，“这个需要很简略”。到土里埋个地雷，这的确不简单，但咱们往往面临的实在场景其实是：“在这片雷区里加一个雷”，而雷区里哪里有雷，任何人都不晓得。

什么是复杂性

咱们始终在说零碎很简单，那到底什么是复杂性？对于简单的定义有很多种，其中比拟有代表的是 Thomas J. McCabe 在 1976 提出的感性派的复杂性度量，与 John Ousterhout 传授提出的理性派的复杂性认知。

感性度量

复杂性并不是什么新概念，早在上世纪 70 年代，软件就曾经极其简单，开发与保护的老本都十分高。1976 年 McCabe&Associates 公司开始对软件进行构造测试，并提出了 McCabe Cyclomatic Complexity Metric，咱们也称之为 McCabe 圈复杂度。它通过多个维度来度量软件的复杂度，从而判断软件以后的开发 / 保护老本。

理性认知

复杂度高的代码肯定不是好代码，但复杂度低的也不肯定就是好代码。John Ousterhout 传授认为软件的复杂性绝对感性的剖析，可能更偏理性的认知。

Complexity is anything that makes software hard to understand or to modify\
译：所谓复杂性，就是任何使得软件难于了解和批改的因素。

  • John Ousterhout《A Philosophy of Software Design》

50 年后的明天，John Ousterhout 传授在 A Philosophy of Software Design 书中提到了一个十分主观的见解，复杂性就是任何使得软件难于了解和批改的因素。

模糊性与依赖性是引起复杂性的 2 个次要因素，模糊性产生了最间接的复杂度，让咱们很难读懂代码真正想表白的含意，无奈读懂这些代码，也就意味着咱们更难去扭转它。而依赖性又导致了复杂性一直传递，一直外溢的复杂性最终导致系统的有限腐化，一旦代码变成意大利面条，简直不可能修复，老本将成指数倍增长。

复杂性的表现形式

简单的零碎往往也有一些非常明显的特色，John 传授将它形象为变更放大（Change amplification）、认知负荷（Cognitive load）与未知的未知（Unknown unknowns）这 3 类。当咱们的零碎呈现这 3 个特色，阐明咱们的零碎曾经开始逐步变得复杂了。

症状 1 - 变更放大

Change amplification: a seemingly simple change requires code modifications in many different places.

译：看似简略的变更须要在许多不同中央进行代码批改。

  • John Ousterhout《A Philosophy of Software Design》

变更放大（Change amplification）指得是看似简略的变更须要在许多不同中央进行代码批改。比拟典型的代表是 Ctrl-CV 式代码开发，畛域模型短少内聚与收拢，当须要对某段业务进行调整时，须要改变多个模块以适应业务的倒退。

/**
 * 销售捡入客户
 */
public void pick(String salesId, String customerId) {
  // 查问客户总数
  long customerCnt = customerDao.findCustomerCount(salesId);
  // 查问销售库容
  long capacity = capacityDao.findSalesCapacity(salesId);
  // 判断是否超额
  if(customerCnt >= capacity) {throws new BizException("capacity over limit");
  }
  // 代码省略 do customer pick
}

在 CRM 畛域，销售捡入客户时须要进行库容判断，这段代码也的确能够满足需要。但随着业务的倒退，签约的客户要调整为不占库容。而客户除了销售捡入，还包含主管散发、leads 散发、手工录入、数据采买等多个场景，如果没对库容域做模型的收拢，一个简略的逻辑调整，就须要咱们在多个场景做适配能力满足诉求。

症状 2 - 认知负荷

Cognitive load: how much a developer needs to know in order to complete a task.\
译：开发人员须要多少常识能力实现一项工作。

  • John Ousterhout《A Philosophy of Software Design》

认知负荷（Cognitive load）是指开发人员须要多少常识能力实现一项工作。应用功能性框架时，咱们心愿它操作简略，部署简单零碎时，咱们心愿它架构清晰，其实都是升高一项工作所需的老本。自觉的谋求高端技术，设计简单零碎，减少学习与了解老本都属于轻重倒置的一种。

TMF 是整个星环的支柱，也是业务中台面向可复用可扩大架构的外围。但 TMF 太过简单，认知与学习老本十分高，咱们日常中所面临的一些扩大诉求 99%（或者应该说 100%）都不适宜 TMF，可能通过一些设计模式或者就是一些 if else，可能更适宜解决咱们的问题。

除此之外，还包含一些简略搜寻场景却用到了 blink 等流式引擎，简略后盾零碎通过 DDD 进行构建，几个商品公布的状态机转换用上了规定引擎等等，都属于认知负荷复杂度的一种。

症状 3 - 未知的未知

Unknown unknowns: it is not obvious which pieces of code must be modified to complete a task\
译：必须批改哪些代码能力实现工作。

  • John Ousterhout《A Philosophy of Software Design》

未知的未知（Unknown unknowns）是指必须批改哪些代码能力实现工作，或者说开发人员必须取得哪些信息能力胜利地执行工作。这一项也是 John Ousterhout 传授认为复杂性中最蹩脚的一个表现形式。

当你保护一个有 20 年历史的我的项目时，这种问题的进去相对而言就没那么意外。因为代码的凌乱与文档的缺失，导致你无奈掌控一个 500 万行代码的利用，并且代码自身也没有显著体现出它们应该要论述的内容。这时“未知的未知”呈现了，你不晓得改变的这行代码是否能让程序失常运行，也不晓得这行代码的改变是否又会引发新的问题。这时候咱们发现，那些“上帝类”真的就只有上帝能援救了。

为什么会产生复杂性

那软件为什么越来越简单，是不是缩小一些犯错就能防止一场浩劫呢？回顾那些简单的零碎，咱们能够找到很多因素导致系统腐化。

  1. 想简略图省事，没有及时治理不合理的内容
  2. 短少匠心谋求，对恶浊代码熟视无睹
  3. 技术能力不够，无奈应答简单零碎
  4. 交接过渡缺失，三无产品简直无奈保护

除了上述内容外，还能够想到很多理由。但咱们发现他们如同有一个独特的指向点 – 软件工程师，仿佛所有简单的源头就是软件工程师的不合格导致，所以其实一些邪恶的根因是咱们本人？

1、对立的中国与决裂的欧洲

欧洲大陆面积大体与中国相当，但为什么欧洲是决裂的，而中国是对立的。有人说他们文化不一样，也有人说他们语言不通是次要起因，也有人说他们缺一个秦始皇。其实咱们回顾欧洲的历史，欧洲还真不缺一个大一统的帝国。罗马帝国已经让地中海成为本人的内海，拿破仑鼎盛时期主持着 1300 万平方公里的领地。欧洲也曾呈现过平凡的帝国，但都未走向对立。

咱们再察看地图，其实除了中国、俄罗斯以外，全世界 99% 的国家都是小国。决裂才是常态，对立才不失常。马老师也曾说过，胜利都有必然性只有失败才存在必然。只有极少国家才实现了大一统，所以咱们不应该问为什么欧洲是决裂的，而应该问为什么中国是对立的。类比到咱们的软件也同样如此，简单才是常态，不简单才不失常。

2、软件固有的复杂性

The Complexity of software is an essential property, not an accidental one.

译：软件的复杂性是一个基本特征，而不是偶尔如此。

  • Grady Booch《Object-Oriented Analysis and Design with Applications》

Grady Booch 在 Object-Oriented Analysis and Design with Applications 中提出这样一个观点，他认为软件的复杂性是固有的，包含问题域的复杂性、治理开发过程的困难性、通过软件可能实现的灵活性与刻画离散系统行为的问题，这 4 个方面来剖析了软件的倒退肯定随同着简单，这是软件工程这本迷信所必然随同的一个个性。

Everything, without exception, requires additional energy and order to maintain itself. I knew this in the abstract as the famous second law of thermodynamics, which states that everything is falling apart slowly.

译：世间万物都须要额定的能量和秩序来维持本身，无一例外。这就是驰名的热力学第二定律，即所有的事务都在迟缓地土崩瓦解。

— Kevin Kelly《The Inevitable》

Kevin Kelly 在 The Inevitable 也有提过相似的观点，他认为世间万物都须要额定的能量和秩序来维持本身，所有的事物都在迟缓地土崩瓦解。没有内部力量的注入事物就会逐步解体，这是世间万物的法则，而非咱们哪里做得不对。

软件架构治理复杂度

为软件系统注入的外力就是咱们的软件架构，以及咱们将来的每一行代码。软件架构有很多种，从最早的单体架构，到前面的分布式架构、SOA、微服务、FaaS、ServiceMesh 等等。所有的软件架构万变不离其宗，都在致力解决软件的复杂性。

架构的实质

编程范式指的是程序的编写模式，软件架构倒退到明天只呈现过 3 种编程范式(paradigm), 别离是结构化编程，面向对象编程与函数式编程。

  • 结构化编程勾销 goto 移除跳转语句，对程序控制权的间接转移进行了限度和标准
  • 面向对象编程限度 指针 的应用，对程序控制权的间接转移进行了限度和标准
  • 函数式编程以 λ 演算法 为核心思想，对程序中的赋值进行了限度和标准

面向对象的五大设计准则 S.O.L.I.D。依赖倒置限度了模块的依赖程序、繁多职责限度模块的职责范畴、接口隔离限度接口的提供模式。

软件的实质是束缚。商品的代码不能写在订单域，数据层的办法不能写在业务层。70 年的软件倒退，并没有通知咱们应该怎么做，而是教会了咱们不该做什么。

递增的复杂性

软件的复杂性不会凭空隐没，并且会逐级递增。针对递增的复杂性有 3 个观点：

  1. 模糊性发明了简单，依赖性流传了简单
  2. 复杂性往往不是由单个劫难引起的
  3. 咱们能够容易地压服本人，以后变更带来的一点点复杂性没什么大不了

已经小李跟我埋怨，说这段代码切实是太恶心了，花了很长时间才看懂，并且代码十分生硬，而正好这个需要须要改变到这里，代码真的就像一坨乱麻。我问他最初是怎么解决的，他说，我给它又加了一坨。

编程思维论

战术编程

其实小李的这种做法并非是一个个体行为，或者咱们在遇到简单代码时都曾这样苟且过，John 传授这种编程办法称之为“战术编程”。战术编程最次要的特点是快，同时具备如下几个特点。

  1. 以后肯定是最快的
  2. 不会破费太多工夫来寻找最佳设计
  3. 每个编程工作都会引入一些复杂度
  4. 重构会减慢当前任务速度，所以放弃最快速度
@HSFProvider(serviceInterface = AgnDistributeRuleConfigQueryService.class)
public class AgnDistributeRuleConfigQueryServiceImpl implements AgnDistributeRuleConfigQueryService {

    @Override
    public ResultModel<AgnDistributeRuleConfigDto> queryAgnDistributeRuleConfigById(String id) {logger.info("queryAgnDistributeRuleConfigById id=" + id);
        ResultModel<AgnDistributeRuleConfigDto> result = new ResultModel<AgnDistributeRuleConfigDto>();
        if(StringUtils.isBlank(id)){result.setSuccess(false);
            result.setErrorMsg("id cannot be blank");
            return result
        }
        try {AgnDistributeRuleConfigDto agnDistributeRuleConfigDto = new AgnDistributeRuleConfigDto();
            AgnDistributeRuleConfig agnDistributeRuleConfig = agnDistributeRuleConfigMapper.selectById(id);
            if(agnDistributeRuleConfig == null){logger.error("agnDistributeRuleConfig is null");
                result.setSuccess(false);
                result.setErrorMsg("agnDistributeRuleConfig is null");
                return result
            }
            this.filterDynamicRule(agnDistributeRuleConfig);
            BeanUtils.copyProperties(agnDistributeRuleConfig, agnDistributeRuleConfigDto);
            result.setSuccess(true);
            result.setTotal(1);
            result.setValues(agnDistributeRuleConfigDto);
        } catch (Exception e) {logger.error("queryAgnDistributeRuleConfigById error,", e);
            result.setSuccess(false);
            result.setErrorMsg(e.getMessage());
        }
        return result;
    }
}

咱们看下面这段代码，是一段查问散发规定的业务逻辑。尽管性能可能 work，但不标准的中央其实十分多

  1. Facade 层定义全副逻辑 – 未做构造分层
  2. 业务与技术未做拆散 – 耦合接口信息与业务数据
  3. Try catch 满天飞 – 短少对立异样解决机制
  4. 没有规范化的日志格局 – 日志格局凌乱

但不可否认，他肯定是以后最快的。这就是战术设计的特点之一，永远按以后最疾速交付的计划进行推动，甚至很多组织激励这种工作形式，为了使性能更快运作，只重视短期收益而疏忽长期价值。

战术龙卷风

Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado.

译：简直每个软件开发组织都有至多一个将战术编程施展到极致的开发人员：战术龙卷风。

  • John Ousterhout《A Philosophy of Software Design》

将战术编程施展到极致的人，叫战术龙卷风。战术龙卷风以腐化零碎为代价换取以后最高效的解决方案（或者他本人并未感觉）。战术龙卷风也有如下几个特点：

  1. 是一位多产的程序员，没人比龙卷风更快实现工作
  2. 总能留下龙卷风后覆灭的痕迹留给前人去清理
  3. 是真的很卷

一些组织甚至会将战术龙卷风视为英雄，为什么无能得又多又快？因为他将老本放到了将来。软件工程最大的老本在于保护，咱们每一次代码的改变，都应该是对历史代码的一次整顿，而非繁多的性能沉积。龙卷风能博得当初，但终将失去将来，而这个失败的将来或者须要全团队与他一起买单。

策略编程

John 传授提出与战术编程绝对的是策略编程，策略编程更重视长期价值，不满足于性能 work，致力于制作杰出的设计，以满足对将来扩大的诉求（留神，不要适度）。策略设计有如下 4 个特点

  1. 工作代码远远不够
  2. 引入不必要的复杂度不可承受
  3. 一直对系统设计进行小幅改良
  4. 投资心态（每位工程师都须要对良好的设计进行间断的大量投资 10~20%）

John Ousterhout 传授在 A Philosophy of Software Design 书中提到了策略设计与战术设计的总成本投入。随着工夫的流逝，策略设计能够无效控制软件老本，但战术设计会随着工夫的推移线性递增。这与 Martin Fowler 在 Patterns of Enterprise Application Architecture 这本书中所提的对于数据驱动与畛域驱动对于复杂度的治理是同样的含意，要致力于长期的价值投资。

零碎的窘境与演进

没有零碎是人造简单的，为了疾速实现工作一直引入新的复杂度至零碎逐步腐化，有限增长与有限传递的复杂度让软件需要越来越难“疾速实现”。当有一天咱们意识到零碎的复杂性时再试图通过策略设计进行软件的迭代，你会发现举步维艰，一处很小的批改须要投入大量的基建修复，最终咱们不得不向老本抬头，一直再通过战术设计有限的苟且。

A condition that is often incorrectly labeled software maintenance. To be more precise, it is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation. Unfortunately, reality suggests that an inordinate percent- age of software development resources are spent on software preservation.

译：咱们总是说咱们须要“保护”这些老零碎。而精确的说，在软件倒退过程里，只有咱们修改谬误时，才是保护；在咱们应答扭转的需要时，这是演进；当咱们应用一些极其的伎俩来放弃古老而陈旧的软件持续工作时，这是爱护（苟且）。事实证明咱们更多的工夫是在应答最初一种情况。

  • Grady Booch《Object-Oriented Analysis and Design with Applications》

如同 Grady Booch 在 Object-Oriented Analysis and Design with Applications 中所提到的观点，当咱们应用一些极其的伎俩来放弃古老而陈旧的软件持续工作时，这的确是一种苟且。咱们小心翼翼、集成测试、灰度公布、及时回滚等等，咱们没有在“保护”他们，而是以一种俊俏的形式让这些俊俏的代码持续可能胜利苟且上来。当代码变成意大利面条时，将简直是不可能修复，老本将成指数倍增长，并且仿佛咱们的零碎曾经存在这样的代码，并且可能还在继续减少中。

架构伪论

在架构设计中，总有一些软件工程师所深信的诗和远方，但到不了的乌托邦不肯定就是遥不可及的美妙圣地，实则也可能是对系统有益甚至无害的架构设计。这里列举其中 2 条可能存在的架构伪论。

1、好的代码自解释

Comments do not make up for bad code

译：正文不是对劣质代码的补救

  • Martin Fowler《Clean Code》

Martin Fowler 在 Clean Code 书中提到正文不是对劣质代码的补救，以前我也始终深信如果代码足够好是不须要正文的。但实则这是一个伪命题，John 传授这么评估它‘good code is self-documenting’is a delicious myth。

/**
 * 批量查问客户信息
 */
public List<CustomerVO> queryCustomerList(){
  // 查问参数筹备
  UserInfo userInfo = context.getLoginContext().getUserInfo();
  if(userInfo == null || StringUtils.isBlank(userInfo.getUserId())){return Collections.emptyList();
  }
  LoginDTO loginDTO = userInfoConvertor.convert(userInfo);
  // 查问客户信息
  List<CustomerSearchVO> customerSearchVOList = customerRemoteQueryService.queryCustomerList(loginDTO);
  Iterator<CustomerSearchVO> it = customerSearchVOList.iterator();
  // 排除不合规客户
  while(it.hasNext()){CustomerSearchVO customerSearchVO = it.next();
    if(isInBlackList(customerSearchVO) || isLowQuality(customerSearchVO)){it.remove();
    }
  }
  // 补充客户其余属性信息
  batchFillCustomerPositionInfo(customerSearchVOList);
  batchFillCustomerAddressInfo(customerSearchVOList);
  return customerSearchVOList;
}

这段代码咱们能够很轻松的在 5 秒内看明确这个函数是做什么的，并且晓得它外部的一些业务规定。有限的公有办法封装会让代码链路过深，有限类的拆解会造成更多网状依赖，至多有 3 点内容，让咱们绝不能摈弃正文。

  1. 无奈精准命名
    命名的含意是形象实体暗藏细节，咱们不能在一个名字上赋予它全副的信息，而必要的正文能够完满的进行辅助。
  2. 设计思维的论述
    代码只能实现设计不能论述设计，这也是为什么一些简单的架构设计咱们须要文档的撑持而非代码的‘自解释’，在文档与代码之间的空隙，由正文来填补。
  3. 母语的力量
    这点尤其适宜咱们中国人，有时并不是因为正文少代码多，所以咱们下意识会首先看代码。而是咱们几十年感触的文化，让咱们对中文与 ABC 具备齐全不一样的感观。

2、永远谋求最优雅

雷布斯曾自夸本人写的代码像诗一样优雅，谋求优雅的代码应该是每个软件工程师的心中的圣地。但有时存在一些不优雅，存在一些‘看似不合理’并不代表就不对，反而有时在谋求更优雅的路上咱们继续跑偏。

The goal of software architecture is to minimize the human resources required\
to build and maintain the required system.

译：软件架构的终极目标是，用最小的人力老本来满足构建和保护该零碎的需要

  • Robert C.Martin《Clean Architecture》

Robert C.Martin 在 Clean Architecture 一书中提到了架构终极目标，用最小的人力老本来满足构建和保护该零碎的需要。架构始终是咱们解决复杂度的一个工具，如果以后零碎并不简单，咱们不须要为了所谓的优雅去过分革新与优化它，继续将老本置在一个较低水位，就是软件最好的解决办法。

业务简略的零碎不利用 DDD 架构，弱交互场景也无需进行前后端拆散，哪怕是邓总设计师在布局新中国的倒退上，也是制订了一套‘中国特色社会主义’制度。不要盲从一些教条的观点，抉择适宜本人的，管制在可管制范畴内，既不适度也不缺失。毕竟没有相对的优雅，甚至没有相对的正确。

写在最初

很多人认为做业务开发显得没那么有挑战性，但其实正好相同。最难解决的 bug 是无奈重现的 bug，最难解决的问题域是不确定性的问题域。业务往往是最简单的，面向不确定性设计才是最简单的设计。软件工程学科最难的事件是形象，因为它没有规范、没有办法、甚至没有对错。如何在软件固有的复杂性上找到一条既不适度也不缺失的路，是软件工程师的一生课题，或者永远也无奈达到，或者咱们曾经在路上了。

参阅书籍：

  • 《A Philosophy of Software Design》
  • Object Oriented Analysis and Design with Applications
  • 《Clean Code》
  • 《Clean Architecture》
  • 《Patterns of Enterprise Application Architecture》

关注【阿里巴巴挪动技术】，阿里前沿挪动干货 & 实际给你思考！

正文完
系统
发表至： 系统
2022-06-17
 0
关于系统:电脑正常做系统
关于系统:主动发现系统稳定性缺陷混沌工程-京东云技术团队
关于系统:线上开票系统设计实践
关于系统:合作创新携手共赢共筑坚实数字底座