揭秘！系统复杂性是如何 “炼成” 的？

在软件开发的广袤领域里，系统复杂性犹如一个无形的幽灵，悄无声息地影响着项目的可维护性与可扩展性。究竟何为系统复杂性？凡是给软件的理解与修改制造障碍的因素

而其中，偶然复杂性扮演着极为关键的角色

1）偶然复杂性常常源于设计的缺失。缺乏清晰的归类抽象，对设计原则的忽视，使得 ServiceImpl 沦为一个大杂烩，包揽各种功能。脚本代码虽在初期能带来易于理解的便利，但随着时间推移，其弊端逐渐显露：健壮性差，维护成本呈指数级增长，并且由于缺乏统一架构规范，相同逻辑难以复用，代码犹如一盘散沙。

2）技术架构上固件代码，对 Dao、jimdb 等中间件的过度依赖，破坏了原本清晰的层次结构。从 Controller 到 service 的调用变得混乱无序，RPC 微服务的三层架构逐渐崩塌，简化为两层甚至一层。这不仅使得业务功能的共享成为奢望，更让开发工作重心偏移，将 “写业务逻辑” 错误地等同于 “写数据库逻辑”，也就是无休止地编写 CRUD 代码。

3）在开发理念与流程不够重视，一些短视的观念也在不断滋生复杂性。 “这个问题影响不大”、“只要功能实现，代码是否优雅无关紧要” 等想法大行其道。时间管理的混乱，导致 “没时间做技术方案”、“没时间进行 CodeReview” 等情况频发。面对问题，总是以 “临近上线，先放一放，后续再改” 为由拖延，然而往往后续也不了了之。不仅如此，有时技术方案将简单问题人为地复杂化，业务与产品方案也跟风变得繁琐，技术人员只是机械地按要求完成任务，却未曾深入思考如何从根源上降低复杂性。

4）技术方案将简单问题人为地复杂化，业务与产品方案也跟风变得繁琐，技术人员只是机械地按要求完成任务，却未曾深入思考如何从根源上降低复杂性。