复杂系统设计基本注意事项

一、软件复杂性度量方法

（一）McCabe度量方法

（二）John Ousterhout度量方法

（三）一般建议

二、复杂性带来的危害

（一）修改扩散（Modification Diffusion）

（二）认知负担（Cognitive Burden）

（三）不可知性（Unpredictability）

依赖性问题

代码模糊性问题

（二）解决之道

前提：持续改进

解决依赖问题

横向分层

纵向分模块

解决模糊性问题

命名

注释

文档

一、软件复杂性度量方法

系统复杂性是指系统的构建、运作和维护过程中涉及到的多个因素、组件、关系和交互的综合程度。认识软件的复杂性之前，需要找到合适的方法来度量一个软件系统是否复杂，以及复杂度有多少。

（一）McCabe度量方法

McCabe度量方法，也称为环路度量法，是一种用于衡量源代码复杂性的方法。它的核心思想是通过计算程序中的控制流结构中包含的条件分支的数量来度量代码的复杂性。这个方法的主要指标是圈复杂度（Cyclomatic Complexity），通常表示为V(g)。

McCabe度量方法的计算公式为:

V(g) = p + 1

其中，

V(g) 表示圈复杂度。
p 表示程序中的条件分支的数量，包括if语句、switch语句、while循环、for循环等。这些条件分支会影响程序的控制流，因此被用于计算复杂性。

核心思想和步骤如下：

首先，构建程序的控制流图（Control Flow Graph）。控制流图是一个图形表示，它显示了程序中的各种控制结构、条件语句和循环，以及它们之间的连接和依赖关系。
确定控制流图中的节点和边。节点通常代表程序中的基本块（一组连续的语句），而边表示不同块之间的控制流转移。
计算圈复杂度。圈复杂度等于程序的节点数（N）减去边的数量（E），再加上2。也可以表示为：

V(g) = N - E + 2

这是因为一个程序的线性结构会有一个基本圈复杂度值为1，然后每个条件分支和循环会增加一个。
圈复杂度的值用于衡量程序的复杂性。较高的圈复杂度值表示程序有更多的分支和循环，这可能意味着更难理解、测试和维护代码。较低的圈复杂度值通常意味着代码更简单和可维护。

McCabe度量方法的主要目标是帮助开发人员识别潜在的复杂性问题，以改进代码的质量和可维护性。通过定量的方式来度量代码的复杂性，可以更容易地决定是否需要简化代码或重构代码以降低其复杂性，从而降低错误的风险，提高代码的可读性和可维护性。

（二）John Ousterhout度量方法

John Ousterhout度量方法是一种用于衡量软件复杂性的方法，它强调了软件系统的实际复杂性，包括时间复杂性和空间复杂性。这个方法的核心思想是考虑开发和维护软件系统的实际成本，而不仅仅是代码的结构复杂性。

Ousterhout度量方法通常涉及两个主要方面的度量：时间复杂性和空间复杂性。

时间复杂性：

时间复杂性衡量了软件系统的执行效率，即程序执行所需的时间和资源。这包括了对算法和性能优化的考虑。
在Ousterhout度量方法中，时间复杂性通常通过以下方式度量：考虑算法的选择和设计、计算机资源（例如CPU周期）的使用，以及代码执行路径的效率。

空间复杂性：

空间复杂性衡量了软件系统在内存中使用的资源，例如内存、数据结构等。这方面的复杂性通常受到内存管理和数据结构设计的影响。
Ousterhout度量方法考虑了数据结构的复杂性、内存管理的效率，以及对资源的有效利用。

计算公式并没有一个通用的标准，而是依赖于具体的应用和系统。核心思想是将时间和空间复杂性的因素纳入考虑，以帮助开发者更全面地理解软件的复杂性。度量的结果可以用于优化程序的性能和资源使用，减少资源浪费和提高系统的效率。

（三）一般建议

虽然没有一种单一的度量方法能够完全准确地量化系统的复杂性，但这些方法在提供定性和定量指导方面非常有价值。它们为开发人员和团队提供了一些基本的工具，以便更好地理解、评估和管理软件的复杂性。以下是一些相关观点：

指导思想：这些度量方法为开发人员提供了指导思想，使他们更容易识别潜在的复杂性问题。例如，通过McCabe度量方法，开发人员可以注意到过高的圈复杂度，这可能会导致代码难以维护和测试。
重要性识别：这些度量方法有助于开发团队识别关键部分和模块。高复杂性的部分可能需要更多的精力来设计、测试和维护，因此对这些部分的关注更为重要。
性能和资源管理：John Ousterhout度量方法的时间和空间复杂性考虑了系统的性能和资源管理。这有助于开发人员优化程序，以提高效率和资源利用。
质量保证：这些度量方法有助于质量保证，可以帮助开发团队更好地管理项目和控制风险。复杂代码通常容易引入错误，而这些度量方法可以帮助开发者识别潜在的问题。

综上所述，虽然这些度量方法可能不是唯一的衡量软件复杂性的方法，但它们为开发人员提供了一些工具，使他们更容易评估和管理复杂性。在软件开发过程中，开发团队可以根据特定项目的需求和目标，选择适当的度量方法，并采取相应的措施，以确保软件系统具有足够的质量、可维护性和性能。

二、复杂性带来的危害

复杂性过高往往会带来很多问题，其中最直接的就是“代码看不懂、逻辑理不清”，如方法的圈复杂度太大，导致读不懂、很小的改动影响点非常多、注释和代码含义不一致导致理解耗时耗力、甚至新需求来了都不知道要改哪里等等，总结下来危害主要体现在以下这三个方面：

（一）修改扩散（Modification Diffusion）

当软件系统复杂度过高时，尤其是代码的圈复杂度过大时，即使进行小的修改也可能会对系统的多个部分产生广泛的影响。这被称为“修改扩散”。

修改扩散使得维护和更新软件变得困难，因为开发人员需要花费大量的时间和精力来追踪和理解修改的潜在影响。这可能导致引入新错误或破坏现有功能。

案例：电子商务网站的购物车功能

假设您正在开发一个大型电子商务网站，其中有一个购物车功能，允许用户将商品添加到购物车，编辑购物车内容以及进行结账。这个购物车功能是整个网站的关键组件之一，因此它的代码相当复杂，包括处理商品添加、数量变化、价格计算、促销应用等多个方面的逻辑。

现在，客户提出了一个小的需求更改：他们希望在购物车中显示每个商品的图片。这似乎是一个简单的需求，但是由于购物车功能的复杂性，它会引发修改扩散问题。

问题表现：

代码依赖性：购物车功能的代码与整个网站的其他部分紧密相连，因此要实现这个小需求，可能需要修改购物车模块、商品信息模块、前端界面、数据库模式等多个部分。

测试复杂性：由于需要涉及多个模块，需要对整个系统进行全面的测试，以确保新需求的修改没有破坏其他功能。

维护成本：在未来，如果有其他修改或更新需求，修改的扩散会导致增加维护成本，因为每次更改都需要小心翼翼地检查潜在的影响。

风险增加：由于修改扩散，有可能引入新的错误或破坏现有功能，从而增加了项目风险。

在这种情况下，更好的做法可能是在系统设计阶段考虑到这种需求，使系统更加模块化和灵活，从而降低修改的扩散。然而，在已经存在复杂性较高的系统中，这种情况很容易发生，强调了复杂性管理的重要性。

（二）认知负担（Cognitive Burden）

复杂的代码和高圈复杂度增加了开发人员的认知负担。他们需要花费更多的时间来理解系统的逻辑和内部工作原理。

随着认知负担的增加，开发人员可能会感到沮丧，因为他们必须处理混乱的代码和复杂的逻辑，这可能降低工作效率。

案例：复杂的金融交易系统

假设您是一家金融机构的开发人员，负责开发和维护一套用于执行金融交易的系统。这个系统包括处理股票、期货和外汇交易的多个模块，以及涉及交易执行、结算、风险管理等多个方面的复杂逻辑。

问题表现：

复杂的业务逻辑：由于金融交易涉及多个市场、产品和法规，系统的业务逻辑变得非常复杂，包括价格计算、订单执行、交易结算、风险控制等多个方面。

代码复杂性：系统的代码基数庞大，包括大量的条件语句、嵌套逻辑、复杂的数据处理等。这使得代码变得难以阅读和理解。

高圈复杂度：不同的金融交易场景可能需要不同的逻辑路径，这会导致高圈复杂度，需要考虑多个条件分支。

维护困难：当需要对系统进行维护、修复错误或满足新法规要求时，开发人员需要深入理解系统的复杂逻辑，这可能需要花费很多时间，因为代码是如此复杂。

错误风险：由于认知负担的增加，开发人员可能会在修改代码时犯错或遗漏一些细节，这可能导致严重的后果，如交易错误或法规违规。

在这种情况下，为降低认知负担，需要采取一些步骤，如模块化代码、提供清晰的文档、使用命名规范和注释来解释复杂的逻辑，以帮助开发人员更容易理解系统并提高工作效率。此外，重构代码以降低复杂度，将大型系统分解成更小的、可管理的部分，也可以有助于减轻认知负担。

（三）不可知性（Unpredictability）

复杂的代码通常伴随着不可知性。这意味着开发人员可能无法准确预测系统在不同条件下的行为，因为复杂性使系统的状态和行为难以理解和掌握。

当软件系统的行为变得不可知时，开发人员很难确定如何处理错误或满足新需求，这可能导致项目延期和不确定性。

案例：医疗保险计费系统

假设您正在开发一个医疗保险公司的计费系统，用于处理医疗保险索赔的计费和支付。这个系统需要处理各种不同类型的索赔，包括医生费用、药品费用、住院费用等。

问题表现：

复杂的业务规则：由于医疗保险领域的法规和业务规则复杂多变，系统的业务逻辑也变得非常复杂，包括不同类型的索赔的计费规则、支付规则、限额规则等。

数据多样性：系统需要处理各种不同的数据，包括医生提供的医疗费用明细、病人信息、药品清单等。这些数据的多样性增加了处理的复杂性。

状态依赖：系统的行为可能受到不同的状态和条件的影响，如病人的医疗记录、政府法规的变化等。这使得系统的行为变得不可知。

不确定性：由于系统的复杂性和不可知性，开发人员难以准确预测系统在不同索赔情况下的行为。这可能导致在处理索赔时出现错误，导致错误的计费或支付，从而引发法律问题或客户不满。

在这种情况下，不可知性可能导致项目的不确定性，因为开发人员无法准确预测系统的行为，这可能导致项目延期和额外的工作。解决这个问题的方法包括更清晰的规则和文档、更好的测试覆盖率，以及确保开发团队充分理解和掌握业务规则和系统行为。此外，采用敏捷开发方法可以在开发过程中更灵活地应对不确定性和变化。

为减轻这些问题，软件开发团队通常采取一些最佳实践，如模块化设计、重构复杂代码、降低圈复杂度、增加注释和文档、使用测试驱动开发（TDD）等。这些方法有助于提高代码的可读性、降低维护成本，减少认知负担，同时也增加了系统的可预测性和可维护性。

三、原因及解决方法

（一）主要原因展述

复杂性问题通常可以追溯到两个主要原因：依赖性问题和代码模糊性问题。这两个问题经常相互交织，导致软件系统变得难以理解、维护和修改。

依赖性问题

外部依赖：过多、复杂或频繁变化的外部依赖（如第三方库、服务、API等）可能引入不稳定性和不确定性，导致系统的稳定性和可维护性问题。
耦合性依赖：高度耦合的系统组件之间的依赖关系可能导致修改扩散，因为一个组件的变化可能会波及多个其他组件，增加了维护的复杂性。
系统内部依赖混乱：当系统内部的模块和层之间的依赖关系不清晰或混乱时，开发人员难以理解和修改代码，因为他们不确定修改如何影响其他部分。
依赖的自身类设计不合理：如果依赖的类或模块自身设计不合理，可能会使代码复杂化，从而增加了修改的困难。

代码模糊性问题

缺乏注释和文档：没有足够的注释和文档，或者注释与代码不一致，会增加开发人员理解代码的难度。
新功能开发不知道改哪里：当代码缺乏清晰的结构和命名规范时，开发人员可能不知道在哪里添加新功能或进行修改，从而引入混乱和错误。

这些问题通常在软件项目的生命周期中积累，特别是在长期维护的情况下。为了降低复杂性和减轻相关问题，开发团队可以采取一系列最佳实践，如模块化设计、解耦合、清晰的文档、注释规范、命名规范、单元测试等。这些方法有助于降低依赖性和提高代码的可读性，从而改善系统的可维护性。

（二）解决之道

前提：持续改进

快速实现功能（战术编程）与进行良好的设计（战略编程）之间的权衡。战术编程和战略编程都有其用武之地，但在实际项目中，通常需要在二者之间找到平衡点。

战术编程（Tactical Programming）

快速实现需求：战术编程侧重于尽快交付功能，对于紧急需求或原型开发可能是有用的。这种方式可以满足客户的迅速需求。
可能引入技术债务：在战术编程中，可能会出现未经考虑的设计缺陷或技术债务，这会导致后续维护和扩展时的困难。

战略编程（Strategic Programming）

长期维护和可维护性：战略编程强调设计、结构和代码质量。它投资于系统的长期健康，提高可维护性和减少技术债务。
可能需要更多时间：战略编程可能需要更多的时间来规划和实施，因此在短期内可能看不到立竿见影的效果。

实施示例：考虑一家电子商务网站，他们面临一个新需求，即实现一个购物车功能，该功能需要在短期内上线以满足销售季的需求。在这种情况下，战术编程可能更合适，团队可以迅速实现购物车功能，以满足季节性销售需求。然而，团队也应该考虑在季节结束后进行战略编程，对购物车功能进行重构，以确保代码的质量和可维护性。

结果：通过战略编程，团队不仅满足了一次需求，还改进了购物车的设计和质量。这意味着未来的需求变更将更容易满足，维护成本更低。

思考问题：

为什么代码需要重构？是因为需求变更、技术债务、性能问题还是其他原因？
重构是被动的还是主动的？是为了解决已知问题，还是为了提前规避潜在问题？

持续的投资和重构可以确保软件系统保持健康，减少未来的问题和维护成本。它类似于进行小型维护，而不是等到系统完全失效后才进行大规模的重写。这种方法通常可以提高系统的可维护性和可用性。

解决依赖问题

解决依赖问题是提高软件系统的可维护性和降低复杂性的关键部分。可以从横向分层（水平分层）和纵向分模块（垂直分模块）两个方面来处理依赖问题：

横向分层（Horizontal Layering）

横向分层是指将系统的不同功能和关注点分为不同的层次，每个层次有不同的责任和关注点。这可以帮助减少横向层次之间的耦合，降低依赖性，以及提高系统的可维护性。以下是一些方法：

分离用户界面和业务逻辑：将用户界面和业务逻辑分离开，使用模式如MVC（Model-View-Controller）或MVVM（Model-View-ViewModel）来确保业务逻辑不依赖于特定的用户界面技术。
分离业务逻辑和数据访问：将业务逻辑与数据访问层分离，这有助于确保业务逻辑不依赖于底层数据存储技术。使用仓储模式（Repository Pattern）或服务来处理数据访问。
分离服务层：将系统的服务层与业务逻辑分离，以便在未来可以更轻松地更改或扩展服务。
使用依赖注入（Dependency Injection）：通过依赖注入，可以将依赖关系从组件内部移到外部，从而更容易进行替换和测试。

纵向分模块（Vertical Module Separation）

纵向分模块是指将系统的不同功能划分为独立的模块或组件，以减少模块之间的依赖性。以下是一些方法：

模块化设计：将系统划分为小而独立的模块，每个模块具有明确定义的责任。这可以减少模块之间的耦合，使其更容易理解和维护。
接口定义：为模块之间的通信定义清晰的接口。这有助于确保模块之间的依赖性受到控制，并可以更容易地替换或升级模块。
松耦合（Loose Coupling）：使用松耦合的设计原则，如依赖倒置原则（Dependency Inversion Principle）和单一职责原则（Single Responsibility Principle），以减少模块之间的依赖性。
事件驱动架构：使用事件和消息传递来实现模块之间的通信，可以降低直接依赖关系，使模块更加独立。

通过横向分层和纵向分模块的方法，可以减少依赖关系，降低系统的复杂性，并提高可维护性。这些方法有助于降低修改扩散，使系统更容易适应需求变化，同时提供更好的代码组织和可理解性。

横向分层

分层架构的目的是：通过关注点分离来降低系统的复杂度，同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。因此横向分层使得每一层的关注点更加聚焦而不是扩散，进而减少甚至避免底层依赖变更带来的影响，从而降低依赖的复杂度。那具体是怎么来分离关注点的呢？接下来用几种架构模式来说明下：

在签约绑卡系统中，结合整洁架构和领域驱动设计架构，最终呈现出来的结果如下：

通过分不同的层，来实现不同的抽象级别，最终以较为简单地实现功能：

依赖倒置解决外部依赖频繁变更问题：采用依赖反转（底层依赖高层）的思想，即签约绑卡系统和外部系统的依赖关系进行反转，使得外部服务依赖于签约绑卡系统。从而屏蔽底层服务细节，实现与外部服务解耦（如大量会员接口、绑卡记录存储问题、会员及网关缺乏数据结构抽象等），并提升高层组件的复用能力。
- 关键词：依赖解耦、变更收敛。
高度抽象核心领域服务，简化上层依赖的复杂性：与业务场景无关，且不依赖任何一层，具备较高的通用型，并保持较高的稳定；签约、绑卡等领域概念更加内聚，提升对业务的理解性。
增加领域服务，将数据和操作内聚：银行卡绑定过程比较复杂，更新卡信息、处理绑定状态等，因此富模型有利于操作起来更加内聚（对象创建、加载、变更等），避免出错。

总结：没有最好的分层架构，适合自己的就是最好的，重点是通过分层来解决复杂依赖问题（依赖变更导致的修改扩散、认知负担等问题）。

纵向分模块

模块强调的是内聚，不内聚的模块会引起什么问题呢？

（1）对外暴露太多实现，造成使用者认知负担过重。

（2）模块修改功能时，很多使用到的地方都要修改，造成修改扩散问题。

那么设计一个好的模块，应该遵循哪些原则呢？

高内聚、松耦合：将模块完成的功能尽量内聚封装起来，在上层实现功能时对下一层级依赖最小化，同时避免模块功能有改动时，修改扩散。
黑盒：尽可能是比较深的模块，将复杂行封装起来，让用的人感觉到简单（举个例子：Unix文件操作），最好让使用者当做黑盒处理，而不用关心模块的实现。

其实有些遵循迪米特法则（最小知识原则）

看一个示例：浅模块VS深模块

改进点：通过构建比较深的模块，使得使用者不用关心模块内复杂的实现（如请求网关签约银行卡并更新卡和通道关系、更新银行卡字段、请求会员保存银行卡对象等），进而达到高内聚、封装复杂性的目的。

解决模糊性问题

命名

命名在编程中起着关键作用，它可以使代码更易于理解、维护和共享。好的命名实践是代码即设计和代码即注释的重要组成部分，因为它可以使代码的含义更加清晰，减少了对注释的依赖。

以下是一些关于命名的最佳实践：

使用描述性的名称：变量、方法和接口的名称应该反映其功能和用途。使用具有意义的名称，使其他开发人员能够快速理解代码的含义。

例如，命名一个变量为paymentChannelId比channelId更清晰，因为它直接表明了它与支付渠道有关。
遵循命名约定：在编程语言和团队中，通常有一些常见的命名约定。遵循这些约定可以提高代码的可读性，例如在Java中使用驼峰命名法。

例如，使用isValid()来表示一个对象的有效性检查是一种常见的命名约定。
避免缩写和缩写：尽量避免使用缩写和缩写，因为它们可能会导致代码的不明确性。使用完整的、易于理解的单词。
不要使用无意义的名称：避免使用像temp、x、foo这样的无意义名称，这些名称不提供任何有用的信息。
命名一致性：在整个代码库中保持命名的一致性。相同概念应该以相同的方式命名，以便开发人员可以更容易地理解和查找变量、方法或接口。
使用名词、动词和形容词：根据命名的对象或操作，选择名词、动词或形容词作为前缀或后缀，以增加名称的表现力。

例如，使用名词如user、order、动词如create、delete，或形容词如valid、active。

好的命名使代码变得更加自解释，减少了阅读和维护代码时的认知负担。通过遵守这些最佳实践，开发人员可以提高代码质量、可维护性和可读性，减少了对注释的需求，使代码更易于理解和共享。

注释

注释是代码中的重要元素，它们可以帮助其他开发人员理解代码的目的和细节。注释的主要目标是解释那些不太明显或理解成本较高的代码部分，以帮助读者更好地理解代码。

以下是一些关于注释的最佳实践：

重点注释不明显的部分：注释应该集中在那些可能难以理解的、非常关键的部分。这包括算法的复杂部分、跨越多个模块或层的逻辑，以及可能需要特别注意的边界条件。
避免重复注释：不要编写显而易见的注释，这只是在重复代码本身。例如，不需要编写checkSmsSendLimit(cellphone); //手机号短信发送限频校验，因为函数名已经提供了明确的信息。
提供上下文：注释应该提供有关代码目的、意图和上下文的信息。这有助于读者理解为什么这段代码存在以及它的作用是什么。
使用清晰的语言：注释应该使用清晰、简练的语言，避免使用模棱两可的术语。使用通用的编程术语和术语约定，以便其他开发人员可以理解。
维护注释同步：当代码发生更改时，要确保更新相关的注释，以保持它们的准确性。过时的注释可能会引导读者进入错误的理解。
注释代码中的设计决策：如果有特定的设计决策、权衡或原因导致代码采用某种方式，可以在注释中提供这些信息。这有助于其他人理解为什么这样设计。
不要过度注释：避免在整个代码中撒播大量注释。注释应该是有针对性的，针对那些真正需要解释的地方。