PART 01
问题
如何理解业务系统的复杂性？
PART 02
答案
一、背景
近些年，各种中台、低代码平台的推行。目的是为了增加开发效率，让技术专注于业务本身而开发。而业务是通过长期慢慢积累下来的，只有对业务足够了解才能设计出一个好的业务系统。
二、系统复杂的原因
1. 功能之间隐蔽的增加耦合
相信大家在做开发时，时常会碰到一些用户需求。比如A页面需要看到一些数据，这些数据可能会依赖B模块或 B系统，那B系统的这部分数据可能又会依赖C系统。层层依赖后导致这部分功能的后续维护变的极其复杂。原本在这个页面上新增的功能可能开发周期只需要1天，但由于之前逻辑造成的“负担”会使开发周期成倍的增长。
再举个例子，在做BPM的开发时，客户会有一些自己独特的需求。比如在其中某个审批节点时需要触发一些动作。那试想一下如果触发失败，审批节点该不该回退？若不回退，动作如何重试？以及动作失败，该不该让审批人感知到？这就是将业务侵入工作流而引发的一系列问题。
2. 代码腐化
当一个功能的初版有一个比较复杂的逻辑时，随着开发者的遗忘或离开，这些逻辑可能没人能讲的清楚。所以代码注释、技术文档显得尤为重要。但若文档丢失、或是写得不清晰等原因，会导致接手的技术对后续的开发畏手畏脚，从而可能导致通过ifelse来嵌套一层又一层的新逻辑。而随着技术的更换，这些代码将变得越来越难以维护。而重构代码又属于”还债”，不仅增加了成本，又伴随着极大的风险。
三、总结
我认为功能之间的耦合和代码腐化都是不可避免的，这也是导致系统越来越复杂，维护成本越来越高的根因。但我们可以最大限度的延缓代码腐化的速度。比如写好注释、管理好技术文档、采用设计模式的思想来编写代码等。经历过长时间、多场景的验证后，我们也可以对之前的代码可以进行适当的重构。而功能之间导致的耦合，则需要技术对业务有足够深刻的认知和理解。当技术精通某一业务领域，可以是生产、采购或者财务等，在设计系统时就可以更加合理，扩展性也会更高。所以对于程序员来讲，我们不仅仅要提升自己的技术能力，业务能力对于我们来讲也是很重要的。只有二者兼备才可以设计出一个好的系统。
作者丨胡 伟
审核丨邓金边
编辑丨王 锐
