一、背景
最近走查组内项目的时候，发现有一块的代码非常恶心，可能只是去添加一个搜索项，但是业务逻辑就要理解半天。而且，代码逻辑写的非常奇怪，已经很多同事在此基础上迭代过了。我看到的时候都很惊讶，别说如果是新人来处理这块的业务需求，我想可能直接就开始怀疑自己了。然后，，，我口中骂骂咧咧的来纠其源头，，，，然后，大无语事件发生了，小丑竟然是我自己～，呜呼
稳住，不慌，分析下是什么原因，导致我起头写了这xxx的代码。首先，从最开始的代码来看，处理当时的业务场景是完全没有问题的。但是，随着业务需求的迭代，场景的扩充，所以就开始逐渐走向了“变形”。大致的代码如下图所示： xxx内部代码xxx
看到是不是也想开始吐槽了，忍住，忍住！
究其原因，其实就是当时的技术方案没做好，没有考虑后续的迭代场景，导致可维护性和扩展性比较差。那么如何才能避免这种现象再次发生呢？
我们觉得其实我们在处理业务需求的时候，可以多花一些时间在技术方案的设计和业务沉淀上，好的技术方案不能说“一劳永逸”，但是也绝对能owern住很多后续的迭代。所以，我觉得技术方案真的太太太重要了，无论是对后续的业务维护还是对自己的个人成长。所以建议大家可以写完技术方案后，拉组内的同学进行技术方案评审
来来来，话说回来了，那么是不是做了好的技术方案就能owner住所有的场景，就可以高枕无忧了呢？达咩，达咩，别再想了，真这样就失业了。我个人观点哈：所有的代码，最终都会走向一个结果——重构。我觉得，不管对于何种语言，重构都是软件开发过程中不可或缺的一部分。那下面我们就来具体说说重构。
二、重构
1.什么是重构，为什么要重构
- 不改变软件可观察行为的前提下，改善其内部结构
- 以提高理解性和降低修改成本
摘自《重构 - 改善既有代码的设计》
无论是多么优秀的代码，都是有一个从简单到复杂的迭代过程，在这个过程里，在不影响业务项目的使用情况下，需要不断的对代码进行优化，保持或者增加代码的可读性，可维护性。举个栗子：衣服脏了就洗，破了就补，不合穿就扔。
然后看下，什么时候重构
我觉得，重构应该是要贯穿整个项目的开发和维护周期的，可以说重构就是开发的一部分。具体可以参考下面：
- 大量重复工作，需求难以处理，上手成本过高
- 不能快速定位问题
- 逻辑不清，缺少备注
- 可读性、理解性差
- 代码引起性能问题
那么重构需要抽出特定的时间来进行嘛？
我觉得大重构是需要的，小重构的话跟着需求就可以进行，所以不要再拿着没时间的接口，继续“补丁上落补丁”了
再看下，重构后的衡量标准
- 代码可读性高，复杂度低
- 后续迭代，花费的时间成本小
- 调用关系清晰，方便定位bug
- 有利于功能重用
- 提升后续迭代体验
重构的技巧
a、提取重复代码，封装成函数
这个在我们开发的过程中估计是最常见的操作了吧，尤其是一些数据格式的转换方法，零散在项目的各个文件中，针对这个，我们组现在是把这些通用的方法，抽离在了# @crmbest/util中，访问地址为：xxx
b、拆分功能太多的函数
相信大家在处理需求的时候，或多或少都见过一些“庞大”的函数，严重者一个方法行数过百，，，可读性非常的差。所以我们应该去把函数按照功能、业务逻辑进行拆分，确保函数的可读性。
c、变量/函数改名
在开发的时候，命名尽量语义化，这样可读性才更高。千万不要写那些代号啥的，，，可能只有你自己看得懂。还有拒绝魔法数字，推荐使用我们的通用方法：JsEnum/TsEnum,上面链接里就有案例哦～
折分嵌套条件表达式
这又是是个常见且头疼的问题，总是在代码里看到if，if，if。建议将判断条件进行整合，避免出现多级嵌套，当然也不要过于精简，，，导致阅读困难，记得写注释哦
循环不要超过两层
循环超过两层，我想程序还没趴下，开发者自己就要趴下了吧。后续维护者大概率也会和我一样骂骂咧咧，所以，不要坑害自己，尽量拆分～
最后想说，重构从来不是一次性的行为，不可能“一劳永逸”。重构，本来就是我们开发的一部分，或早或晚而已吧。希望大家在开发过程中，遇到垃圾代码，一定要“该出手时，就出手”，千万不要“一忍再忍”，让每个后续维护者都“徒悲伤”。
