丁哥看软件（八）：复杂度的关注点

现在来谈一谈复杂度的问题，软件开发中的复杂度当然是越低越好。一般谈到复杂度，我们可能想到了各种逻辑上的复杂度，设计上的复杂度，实际上在软件过程中复杂度涉及到方方面面，我们来看一下，具体有哪些方面我们需要注意复杂度的问题。

第一是命名规则。先举个例子，我定一个变量叫word。有的人喜欢把它写成wd。这个就增加了这个变量定义的复杂度，你从wd很难明白，这个变量是word的意思。

不管是变量的命名还是函数的命名，我们都希望看到名字，我们应该能够理解这个变量或者函数大体是关联到什么样子的事情。

所以谨慎的使用缩写是避免命名规则复杂度提高的重要前提。

第二是程序逻辑的复杂度。线性顺序执行的复杂度为1, 出现分支以后要乘以分支的个数。分支可以是条件判断也可以是循环。所以尽可能的避免分支的出现是降低程序逻辑复杂度的重要手段。 

如果程序分支不可避免，要尽可能的把程序分支放到最高的逻辑层。这样做的目的是为了避免在下层处理的时候出现发散式的分支。发散式的分支会急剧的增加程序的复杂度。

复杂度越高，程序越难维护，复杂度超过一定程度，人类程序员是无法处理的。

第二是架构设计的复杂度。架构设计涉及到模块设计和系统设计。要尽可能的把一些公用的模块或者子系统抽取出来，比如安全相关的，日志相关的，工具相关的等等，这些公用的功能可能会被所有其他的业务模块或系统所调用。

在调用这些公用功能的时候，越简单越好，并且调用者不需要关心具体的内部实现，只需要知道如何使用就可以了。

这样做的目的是让程序员专注到业务代码的设计上来。

第三是系统部署的复杂度。系统部署包含几个不同的阶段如开发阶段，测试阶段和生产阶段。不管是哪个阶段，部署的步骤越少越不容易出错。有些系统天然的需要很多指令的配置，如果是这样的情况，需要编写一个批处理的文件来简化外部使用者的部署步骤，把多个步骤变成一步。 

与部署相关联的还有集成部分。如果能够实现自动化或者从模板中创建那是非常好的状态。

第四是测试的复杂度。测试分白盒测试和黑盒测试。白盒测试的复杂度直接关联着代码层级的复杂度，代码层级的复杂度越高，当然白盒测试的复杂度也就越高。

白盒测试需要注意的一个重要问题是不要使白盒测试这部分的代码脱离实际业务代码的设计。也就是说白盒测试它的依附对象就是我们实际的业务代码，从架构设计上说是一个附属层，不要试图在这里使用什么软件设计艺术或者所谓的编程艺术。 

这种代码的风格就是简单直接，复杂度线性化。

黑盒测试的复杂度来自于业务需求分析。要有非常清晰的文档说明，需要对测试步骤和预期结果写的非常清楚。

第五是技术的复杂度。技术的发展趋势一般是越发展越简单，功能越强大。那么在设计和开发的过程中，要避免使用老旧的技术。关于技术框架的选择，要提前做好调研。前端选什么框架，要不要选择某些UI库，后端选什么框架，要不要选择某些程序库，原则上是为了简化我们的学习过程，提高开发效率，增强整个项目的可维护性。需要具体问题具体分析。

第六是队伍结构的复杂度。队伍构成一定要短小精悍，人多不一定好办事。像亚马逊提倡的是两张披萨团队，意思是说整个团队两张pizza就能吃饱。大体估算就是10人左右的一个队伍。当然这只是一个参考指标。

整个队伍的目标一定要明确。所有的人都向着那个目标迈进，分工可以不同，但是目标一定要一致。

目标+分工是队伍成功运作的关键。具体来说就是把目标分成多个任务，每个任务里又可以分成小任务，那所有的人都去做对应的任务，自己让自己忙起来，而不是别人让你忙起来。