重构存在的现状

                                                         重构存在的现状

       首先让我们了解下重构，重构是存在风险的：重构代码是危险的，代码的变化会导致测试的压力很大。除非有必要的理由，否则不要轻易重构。

       想想我们为什么要重构：

       1.原有的系统太过庞大，需要拆分，重新架构

       2.原有的技术存在瓶颈，无法满足扩展

       3.业务不断发展，需要改进或重新设计业务，来满足不断发展的业务需求

       4.原来的系统开发太烂了，维护的成本，包括修改、增加新的功能、代码逻辑太复杂、人员流失。。。

 

      于是我们开始考虑重构，怎么重构，你考虑清楚没有？

       假如现状是这样：

• 代码逻辑对你来说过于复杂，而且没有时间去分析它。
• 你没有理解为何之前的开发人员是这样编写代码的。
• 你参与的系统是关键系统，而且时间紧。
• 你对团队、应用或者编程语言是新手。
• 你没有足够的时间，去考虑重构的的技术或优化的方案
• 你没有预估重构实在存在的风险
• 你没有强大的测试团队，和优秀的测试人员

       你动手去做了，那么肯定是吃力不讨好的事情，“ 改了这么久，怎么会这么多的错误，怎么你们还不理解业务，你已经影响整个进度和计划了，还不如不重构呢”，哈哈恭喜你中标了，你会碰到困难，碰到外部的压力，就会感到很多无耐，团队的不理解、团队的怀疑、测试资源的不到位、其他部门的冷嘲热讽，风险存在，现实就存在。

 

       假如现状是这样的：

       

• 现有的代码比预期的要复杂，而且你已经分析过它。
• 你所做的改动比现有代码逻辑更加清晰。
• 团队从上至下都达成高度的一致，达成了战略同盟
• 你有时间、人力和财力来增加完整的项目回归测试。
• 现有代码过时了而且效率低下，比如孤立的或者质量差的代码。
• 你和同事讨论过重构代码的好处和风险，并且达成一致。

      你可以动手了，想好如何动手吧，做好计划，协调各部门的力量，分步实施，设置里程碑，定时检查重构

      的结果。

      主要从下面几个方面入手：

• 做好计划，方案，细化任务，分步实施，努力把代码的重构安排在较小的开发周期内
• 在开始重构之前，花时间弄清楚复杂的代码逻辑。
• 需要一定的方案设计，确定是否大的框架需要整体改变，或者那些需要改变，列出来，画出来。
• 在需要时利用设计模式，不要为了用而用，必须要充分的理由。
• 利用自动化的回归测试来快速验证你的代码更改，这非常重要，如果你还没有准备好自动化回归测试，那么请在重构之前先搭建好测试环境。
• 尽量把更改独立化，方便查找问题。
• 避免疲劳战术，让团队有紧有松，保持清醒的头脑，经常进行交流。
• 确保测试计划包含了所有的回归、功能、负载、性能和用户验收测试。

    McConnell，在代码大全中提到安全测试：

     保存初始代码——在开始重构之前，要保证你还能回到代码的初始状态。用版本控制系统保存一个初始版本，或者把最初正确的文件复制到备份目录中去。

     重构的步伐请小一些——这样才能理解所做修改对程序的全部影响。

同一时间只做一项重构——除非是对付那些最为简单的重构，否则请在同一时间只做一项重构，在进入下一项重构之前，对代码重新编译并测试。

     把要做的事情一条条列出来——伪代码编程过程的自然延伸就是列出一份重构列表，然后你应该按照这份列表从A点一步步走到B点。写一份重构列表能够让你在修改时保持思路连贯。

    多使用检查点——在重构的时候，很容易出现代码没有按照设想正常运行的情况。除了保存初始代码外，在重构中还应在多个地方设置检查点，这样一来，即使你编码时钻进了死胡同，仍然可以让程序回到正常工作的状态。

    利用编译器警告信息——要让一些小错误错过编译器的目光很容易。你最好把编译器的警告级别设置为尽可能苛刻，一旦输入中有这些小错误，编译器就能立刻把它们找出来。

    重新测试——应该把重新测试作为检查所修改代码工作的补充。当然，这点要取决于从一开始你是否就有一套优秀的测试用例。

    增加测试用例——除了重新运行过去做过的那些测试，还应该增加新的单元测试来检验新引入的代码。如果重构使得一些测试用例已经过时，那么就删除这些用例。

    根据重构风险级别来调整重构方法——有一些重构实施起来会比其他重构更为危险。而类似于“用具名常量替代神秘数值”一类的重构则机会不会出现什么问题。涉及到类、成员函数结构、数据路架构等改变，或者对布尔判断等进行修改的重构则极具风险。对于简单的重构而言，你只需要简化整个重构过程，然后简单的对代码重新测试，而不用一次去完成一个重构，也不用进行正式的检查工作。

 

      在国内，那些公司适合做重构：

      1.专注并一直做产品，或平台供应商

      2.技术团队较完善的，产品、架构设计、开发、测试等各条战线都有战斗力的。

      3.有资金和时间投入的

      4.有团队管理、技术牛人的。

      5.大企业，发展稳定的。