都说 2B系统复杂，其实很简单

做过2B系统的都知道，相比于2C的业务，2B的业务流程相对更复杂，处理的问题更专业。由于客户群体是企业，2B业务往往不缺需求，大把的需求等着你去做。随着业务功能的迭代，2B软件系统复杂性日益增加，直到有一天，你会突然发现系统为何变得如此复杂，快要干不动了！

春虫杂记

10年+一线程序员的自留地，记录技术、职场、生活中的点滴。

01

—

2B系统的复杂性

2B业务系统复杂，其复杂性主要体现在哪些方面呢？

    1. 多角色和权限管理：

2B系统通常需要支持多个企业用户角色，每个角色可能有不同的权限和访问级别，这增加了系统设计和管理的复杂性。

    2. 定制化需求：

企业客户常常有特定的业务流程和需求，需要系统提供高度定制化的功能和服务，这可能导致系统架构和代码的复杂性增加。

    3.集成与互操作性：

2B系统通常需要与其他内部或外部的企业系统集成，以实现数据交换、流程协同等，这涉及到复杂的接口设计、协议兼容和数据转换问题。

    4. 大规模数据处理：

企业级应用往往需要处理大量的数据和事务，对系统的性能、稳定性、安全性和数据一致性提出了高要求。

    5. 业务流程复杂性：

企业业务流程通常包含多个步骤、审批环节和决策点，系统需要能够准确地模拟和自动化这些流程，同时保持灵活性以适应变化。

    6. 法规遵从性和安全性：

2B系统可能需要遵守行业规定、数据保护法规和安全标准，这需要在设计和实施过程中充分考虑合规性和安全性措施。

    7. 多租户和隔离性：

如果2B系统是为多个企业提供服务的SaaS（Software as a Service）模式，那么需要实现多租户架构，确保不同企业客户的数据和配置隔离。

    8. 并发和性能优化：

大型企业用户可能会同时进行大量操作，系统需要能够处理高并发请求，并进行性能优化以保证响应时间和资源利用率。

    9. 生命周期管理和升级：

由于企业环境的变化和业务需求的演进，2B系统需要具备良好的扩展性和升级能力，以适应长期的维护和支持需求。

    10.客户服务和培训：

提供有效的客户服务和技术支持，以及针对不同用户群体的培训材料和教程，也是2B系统复杂性的一部分。

以上 10 个点，是 GPT给出的答案，回答很完整，涵盖了 2B 业务系统建设需要考虑的各个方面，相信有过 2B系统建设经验的，会有强烈的共鸣。

2B软件系统设计时，这些方面都会予以考虑。系统建设初期，架构简洁、流程清晰，系统迭代起来很快，开发人员看着整个系统架构和代码，感觉神清气爽。

随着企业的不断接入，各式各样的功能需求逐渐加入到系统中，加上开发周期紧张，版本迭代速度快，软件系统开始变得臃肿、复杂起来。有些系统模块，变得难以理解；有些功能在迭代时，难以进行修改，硬着头皮改完，结果一上线发现有很多遗漏，产生了线上故障。

老板问过来，为什么这么多线上问题？我们回答“系统太复杂了”，老板眉头一皱，“要你是来干什么吃的”！

仔细想想，真的是系统复杂吗？系统复杂点在哪里？凭什么说系统复杂？

02

—

正确认识复杂性

针对 2B系统的复杂性，上面介绍了 10个点，但是对技术人员来说，这些其实是我们系统建设的基本要求。这些方面没做好，然后说是系统复杂，多少有点说不过去。

《人月神话》（软件工程项目管理领域的经典大作）一书中作者将软件复杂度分为本质复杂度（Essential Complexity）和偶然复杂度（Accidental Complexity）。本质复杂度是指问题本身的复杂度，要解决这个问题，无论如何都要去做的事情；偶然复杂度是指在解决问题时，由于采取的方式不当(比如方案不对，工具不行，协同不畅)而带来的复杂度。

上文中提到的 2B 系统的复杂性，可以看作是本质复杂度，这个是我们需要面对的，无法回避。事实上，本质复杂度是确定的，是可以量化的；真正容易带来问题的是偶然复杂度，在整个软件系统生命周期中，技术人员要致力于解决的正是如何降低偶然复杂度。

这里提个醒，日常在讨论方案时，经常会听到说“这个太复杂了”，这个时候我们要辨别一下，这里的复杂指的是本质复杂度，还是偶然复杂度? 如果是本质复杂度，严格来说，不属于技术人员争论的范畴，我们需要跟业务人员去沟通，是否有更简单一些的方案。

那如果是偶然复杂度呢？每个人从自身角度出发，有人认为设计复杂，有人认为并不复杂。当出现这种争执时，怎么去评判谁说的更有道理，有没有一种客观的方式来衡量？

《软件设计的哲学》作者认为，软件系统的复杂性，可以由两个维度来度量。

1. 系统是不是难以理解

2. 系统是不是难以修改

系统难以理解或是难以修改，符合其中的一项，说明系统设计是复杂的。复杂的症状，比如，当需要完成一个功能时，开发人员需要了解许多知识；当新增/修改某个功能时，不能明显的知道要修改哪些代码，这都是危险的征兆。

03

—

如何应对复杂性

业务诉求的复杂，和系统设计的复杂，共同导致了 2B 系统复杂性。应对复杂性，就是要尽可能地降低软件系统的本质复杂度和偶然复杂度。

一、做产品而非需求

2B业务，面对形形色色的客户，每个客户的诉求不同，由于其背景和对软件认知的差异，表达诉求的方式也不同。这个时候，就需要清晰的知道用户真正想要的是什么？

系统经过2-3年的迭代，通常一些基本能力都已经具备。在客户提出诉求时，应当先看一下现有的能力是否已经满足，或者是否可以通过现有能力的组合来满足。

一般来说多数客户都比较好沟通，遇到一些难缠的客户，非常考验商务人员的综合能力。在互联网公司，介于商务和研发之间，一个很重要的岗位是产品。商务能不能有效理解并传达客户的诉求，产品能不能将商务的需求转化为一个合理的产品需求，这些都极大的影响到了软件的本质复杂度。

在之前的公司听商务人员聊天时，提到一句话，一个优秀的商务可以将还没有实现的产品给卖出去。如果商务搞不定客户，产品搞不定商务，那么会有源源不断的奇葩需求给到研发，最终系统一定会变得混乱无序。

做产品而不仅仅是需求，当一个新的诉求来临时，如果现有产品能力不能满足，要从产品层面来看，做这个是会完善整个产品体系，还是会破坏现有产品结构。尽可能多地去完善产品体系，而非不断地叠加特殊需求。

二、打造稳定的系统内核

业务千变万化，但是核心逻辑只有一个。

以储值卡系统为例，底层核心逻辑就是卡的初始化以及余额的增减，这个内核一定是稳定的，不变的。上层的业务可以基于内核进行灵活的扩展。比如，充值、消费、退款、调账等上层业务，都依托于这个基础内核。

内核保证了最核心的资金安全，上层业务可以放心地去扩展。

随着公司的发展，业务会变得越来越复杂，支持业务的软件系统也会逐步膨胀。系统演进过程中的成本，会受到最开始的设计、最初的内核的影响。面对业务的不确定性， 技术的不确定性，外部依赖的不确定性。一个稳定的内核可以将这些不确定性隔离开来。

三、简单设计

好的设计最重要的目标之一就是让系统变得显而易见，怎么能够显而易见，那就是在各个方面力求简单。

    1. 单一职责

单一职责原则（Single Responsibility Principle，SRP）主张每个类或者模块应该只有一个明确的责任或功能。

具体来说，单一职责原则包含以下几个关键点：

• 单一功能：一个类应该只负责一项特定的功能或者职责，而不是多项不相关的职责。这样可以保证类的职责清晰，易于理解和维护。

• 变化的独立性：一个类的变化应该只有一个原因。如果一个类承担了多个职责，那么这些职责可能会因为不同的原因而发生变化，这将导致类的复杂性和耦合度增加。

• 降低耦合：通过将职责分离到单独的类中，可以减少不同职责之间的耦合。这样，当一个职责发生变化时，不会影响到其他职责的实现，从而提高系统的可维护性和稳定性。

• 提高可读性和可维护性：遵循单一职责原则的设计通常更易于理解和维护，因为每个类的职责都是明确的，代码更加简洁和聚焦。

• 降低风险：由于单一职责原则有助于隔离变化，因此在需求变更或系统扩展时，修改一个类的行为不会对其他类产生意外的影响，降低了引入错误的风险。

    2. 表达清晰

清晰准确的表达，有助于技术人员更好的理解系统，降低复杂度。

不清晰的表达，体现在如下几个方面。

• 命名不清晰：变量和函数的名称不具有描述性，难以理解。

• 代码结构不清晰：代码组织混乱，不具有逻辑性和结构性，使其难以理解。

• 缺乏注释和文档：代码缺少适当的注释和文档，不清楚代码逻辑和目的。

• 不一致的编程风格：代码中的编程风格不一致，使其难以读懂。

• 复杂的逻辑：代码采用复杂的逻辑结构，使其难以理解和阅读。

04

—

总结

面对2B业务系统的复杂性，技术人员应当以不变应万变，找到业务的核心逻辑，打造强有力的内核引擎，在内核上进行灵活的扩展，在系统设计时，力求简单。同时，以自身的专业性，与产品和商务人员一道，挖掘客户需求背后的真实诉求，满足客户需求的同时尽可能地降低系统复杂度。

参考

如何从容应对复杂性

https://mp.weixin.qq.com/s/8YD9sqTuZGJEpVZPYY-aBQ

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

https://mp.weixin.qq.com/s/7RSNr_iOJEcfe5fw2hDEeA