重构

最近，正在逐步的熟悉和接手历史项目，发现这方面有很多不规范的地方，可以值得深究。一开始看到重构，相信大家和我一样，都懵了，因为觉得重构这个事情太难了，面临的挑战太大了。其实，重构从复杂度而言，也分大小。我们可从最简单的重构做起。

入门

格式化代码

遵从统一的编码规范

更新注释

注释和函数实际保持一致。由于历史原因，可能很多的代码注释已经和功能牛马不相及，及时更新是个好习惯。

废弃的代码删除

废弃的代码剔除，可以通过工具来全局搜索代码块是否仍然被调用，范围为全局。

变量命名

驼峰命名法，具有实际的业务含义。

条件判断语句

少使用带有反向意义的条件值，思维变得复杂。eg：! isNotFemale(gender)

变量和函数定义与调用的地方超过20行

对于变量而言，可改变变量的定义位置或者分别进行定义。
对于函数而言，考虑函数过大，对函数进行拆分。

进阶

相同代码片段出现次数超过3次

如果在同一个类中，考虑将代码片段提取成单独的函数来进行调用
如果是在有继承关系的类中出现，考虑将函数进行上移（子类方法提到父类）或者用模板方法（父类方法定义模板，子类编写不同实现）来设计。

函数参数超过3个

1、开关参数的滥用
考虑根据功能拆分为两个函数
2、入参尽量作为可读，通过中间变量来修改其值，但也要注意不要有冗余的变量，中间变量的职责单一
3、入参个数太多
考虑提炼成类或结构体来进行

条件判断逻辑过于复杂

考虑将条件判断语句单独提炼成一个方法，方法名观名知其义