软件只有两种复杂度：本质复杂度&偶然复杂度

图自网络

我们知道软件设计的本质是持续对抗软件本身产生的复杂度。

题目中的两种复杂度名称，最早来源自哪里呢？

在《人月神话》这本书中，作者将软件复杂度分为本质复杂度（Essential Complexity）和偶然复杂度（Accidental Complexity）。

这两种复杂度应该怎么理解呢？

我们可以结合下面这段描述来理解这两种复杂度的定义。

一个电商软件必然会包含交易、商品等业务复杂度，因此我们称它们为本质复杂度；而同一个电商软件，可以是基于容器技术实现（也可以不是），可以是基于 Java 编写的（也可以不是），因此我们称由于容器技术或者Java 技术而引入的复杂度，为偶然复杂度。

对于上面的描述是否完全正确的呢？

我们继续分别对本质复杂度和偶然复杂度列举两个更详细的案例。

本质复杂度案例：大型电商平台的实时交易系统

图自网络仅示例

考虑一个大型的电商平台，如淘宝或京东，在高峰时段每秒处理数千甚至数万笔交易。这个系统需要实时处理用户下单、支付、库存更新、物流跟踪等多个环节，并确保数据的一致性和交易的准确性。为了满足这些需求，系统必须具备高并发、低延迟、高可用性等特点。

这种实时交易系统的本质复杂度主要体现在以下几个方面：

1. 数据一致性：系统需要确保在分布式环境下多个数据库和缓存之间的数据一致性。这涉及到复杂的分布式事务、数据同步和冲突解决机制。
2. 高并发处理：系统需要能够处理大量用户同时发起的交易请求，并保证交易的顺序和原子性。这涉及到复杂的并发控制、负载均衡和流量调度技术。
3. 业务逻辑复杂性：电商平台的交易过程涉及到多种角色（买家、卖家、支付平台、物流公司等）和多个环节（下单、支付、发货、收货等），每个环节都有复杂的业务规则和逻辑。
4. 安全性和隐私保护：电商平台需要保护用户的隐私和交易数据，防止恶意攻击和欺诈行为。这涉及到复杂的加密技术、风险识别和防御机制。

由于这些本质复杂度是由电商平台的核心功能和业务需求所决定的，无法通过简单的重构或优化来消除。开发人员需要在设计和实现过程中充分考虑这些因素，并采取相应的技术和架构来解决这些复杂问题。例如，使用分布式数据库和缓存系统来处理高并发和数据一致性问题，采用微服务架构来解耦和扩展业务逻辑，使用人工智能和大数据技术来识别和防御安全风险等。

偶然复杂度案例：

图自网络，仅示例。

1、技术选择：

在软件开发中，选择合适的技术栈和工具对于项目的成功至关重要。然而，不合理的技术选择可能导致偶然复杂度的增加。例如，在一个电商平台中，如果没有充分评估和选择合适的前端框架和后端技术，可能导致开发过程中的不必要的复杂性。

案例：不必要的技术集成

假设一个电商平台决定集成一个复杂的机器学习算法，用于推荐商品给用户。然而，开发团队没有充分了解该算法的复杂性和需求，直接将其集成到现有的系统中。这可能导致系统的复杂性增加，需要额外的资源和维护成本来支持这个不必要的集成。

2、系统设计：

系统设计是软件开发过程中的关键环节之一，它涉及到如何组织代码、设计数据库结构、定义接口等方面。不合理的系统设计可能导致代码的冗余、耦合度高以及难以维护。

案例：缺乏模块化的设计

在一个电商平台中，假设开发团队没有采用模块化的设计思想，将不同的功能模块耦合在一起。当需要修改或扩展某个功能时，可能需要修改整个系统的代码，增加了系统的偶然复杂度。而通过合理的模块划分和接口设计，可以降低代码耦合度，提高系统的可维护性和可扩展性。

3、实现过程中的决策：

在软件开发过程中，开发人员需要做出许多决策，如代码的组织方式、算法的选择、错误处理机制等。不合理的决策可能导致代码的质量下降和偶然复杂度的增加。

案例：过度优化和过早优化

在一个电商平台中，假设开发人员在开发过程中过度优化代码的性能，而忽视了代码的可读性和可维护性。这可能导致其他开发人员难以理解和修改代码，增加了系统的偶然复杂度。另外，过早优化也是一个常见的问题，开发人员在代码还未稳定或需求还未明确的情况下进行性能优化，可能导致不必要的复杂性和资源浪费。

总结以上案例，进行分析，我们可以得出如下确认信息。

与本质复杂度相比，偶然复杂度更多地是由于技术选择、系统设计和实现过程中的决策所引起的。通过合理的架构设计、模块化和抽象化等方法，可以降低这种偶然复杂度，提高系统的可维护性和可扩展性。例如，使用统一的接口标准和数据格式来规范与第三方系统的对接，采用中间件或集成平台来简化接口的开发和维护工作，建立健壮的错误处理和容错机制来应对第三方系统的故障等。