认识达内从这里开始

代码重构是程序员在维护软件或者是增加软件新功能的时候需要备选的一个编程方法，而今天我们就通过案例分析来了解一下，代码重构需要关注哪七个问题。

一、命名规则

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

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

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

二、程序逻辑的复杂度

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

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

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

三、架构设计的复杂度

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

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

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

四、系统部署的复杂度

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

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

五、测试的复杂度

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

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

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

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

六、技术的复杂度

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

七、队伍结构的复杂度

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

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。