对于一个程序员来说，日常最常说的词恐怕就是「复杂」了，这段代码太复杂了，这个逻辑太复杂了，所以，在这篇文章里，我们就好好掰扯掰扯「复杂」到底是怎么产生的，又要怎么去避免。

复杂度的产生

我们先列一下当我们在说「复杂」的时候，到底在说什么。

• 没有模块划分，整个一大坨代码摊在那儿

• 大量的重复代码

• 代码整体逻辑看不懂

• 本来一个很简单的需求，改的时候发现这也要改，那也要改

• 代码没办法迁移，没办法复用

• 整天有莫名的bug出现

• …

上边列的这些问题，其实很多之间是互为因果的，比如模块划分的不好，导致了代码逻辑看不懂，也导致了代码没法复用，代码没法复用，又导致了大量重复代码，重复代码又进一步导致代码逻辑看不懂。

所以，下面我们尝试着规整一下这些问题，看看问题到底在哪。

我觉得，首先可以把代码复杂度的问题简单分个类，一类是代码本身的问题，一类是代码对现实世界的表现力的问题。前者主要关乎代码整体的整洁程度，以及容不容易进行持续的维护；后者则主要影响代码容不容易理解，别人看代码时是否需要大量的背景知识。

对代码本身问题来说，以我的观察，导致代码过度复杂的首要原因就是模块拆分不清晰，甚至没有模块拆分。像上边列的重复代码、无法复用、统一逻辑多处修改等问题，本质原因都在模块拆分。另外有一些命名上的问题，会导致代码进一步不可维护。

关于代码对现实世界的表现力，我觉得一个很大的问题就是代码和现实割裂太严重，导致单纯依靠业务上的背景知识，并不能理解代码的实现方式；同时，当你以一个不符合现实的设计去实现现实需求的时候，可想而知，每一步都会很难。比如说，一个展示用户机票的业务，上游各航司的数据key都是「用户证件号」，那你这儿的key应该是什么呢，也是证件号吗。如果这么做了，然后再如果做了分库分表，可以想一下，「查询用户最近一张机票」这么一个基础功能，实现起来要有多复杂。

其实理到这儿，会发现已经能基本涵盖一开始列的那些问题了。像bug多这类问题，其实是逻辑复杂的一种表现。因为逻辑复杂，看不懂，所以Bug才多。

另外，有一个问题是上边说的每个点，随着程序规模的增加，会出现一个指数级的放大效应。相信很多人可以感受的到，如果有一个5天工作量的需求，和5个1天工作量各自独立的需求，最后做下来，前者实际花费的时间和最后产生的bug都要多很多。

所以，接下来我们就对上边这些提供一些解决方案

解决方案

拆分

首先，重中之重，就是做好拆分，要做好每个层次的拆分，比如微服务的边界怎么划分，哪些内容放到一个类里，哪些内容放到一个方法里。不夸张的说，模块拆分的好，可以解决开发上80%以上的问题。

比如，「把大象装进冰箱需要三步，一打开冰箱门，二把大象放进去，三关上冰箱门」，这就是一个非常合理的模块拆分。当然，对于三步中的每一步来说，都可以进一步细化。比如打开冰箱门包括：握住把手，用力拉两步；把大象放进去，包括，找一个大力士，举起大象，放到冰箱里，松手，四步。

拆分的核心要素是要拆的合理。对于业务逻辑来说，就是要符合对现实世界的认知。比如上面的例子里，你不能强行包一个「用力拉，找大力士，举起大象」这样的方法。但是，这个现象，在实际的业务开发中，实际上非常常见。很多人看到一个方法太长，知道要做下拆分，结果只是随机的从代码里拉住一块，抽了出来。这样，实际上只能让代码看着好一点，无法达到降低复杂度的效果。

另外，拆分没有止境，每个子模块，都可以进一步拆分成更细的子模块，直到这个模块已经足够容易理解。

高内聚

在这儿说内聚，主要就是说要把复杂度控制在最小的范围内。以上边的例子来说，「找大力士」这一步就是最复杂的，因为根本没有这样的大力士。但是，这儿的复杂度只是这个小模块的内部实现，只有这一个小模块复杂，在上层或者其他模块是不应该感受到这个复杂度的。

但是，实际开发中，我们经常看到一些底层很复杂的结构，不断的暴露在系统各个层次、各个模块中，导致复杂度无法收敛。这样，随着项目规模的扩大，整体的复杂度就会呈指数级上升。

命名

这个就比较细节了。命名的核心要求一是要准确，无论是变量名、方法名，看到这个名字，不需要去看代码细节，就能大体了解相关的逻辑。

再一个，命名要具备语境下的一致性。比如程序员，你不能一会叫coder, 一会叫programmer, 否则别人理解起来就很混乱。

其实，到这儿已经就说完了，是不是感到比预想的要简单。事实也是如此，只要做好模块的拆分，合理的将每段代码写在它该在的位置，开发就没有那么复杂。