• (DP)降低代码重构的风险(转载)


    重构是每一个开发人员都要面对的功课,Martin Fowler将其定义为“在不改变软件外部行为的前提下,对其内部结构进行改变,使之更容易理解并便于修改”。技术专家Paul在博客中讨论了重构的风险,并提出了降低风险的措施。

    Paul在文中指出:

    重构代码是危险的,代码的变化会导致测试的压力很大。除非有必要的理由,否则不要轻易重构。我指的重构并不是说把while循环改成for循环,或者把StringBuffer改成StringBuilder,而是指比较大的改动,比如重新方法、函数或者整个类或者包。

    错误的重构时机包括:

    • 代码逻辑对你来说过于复杂,而且没有时间去分析它。
    • 你没有理解为何之前的开发人员是这样编写代码的。
    • 你参与的系统是关键系统,而且时间紧。
    • 你对团队、应用或者编程语言是新手。

    正确的重构时机包括:

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

    如何减低重构风险呢?Paul认为可以从以下几点入手:

    • 利用自动化的回归测试来快速验证你的代码更改,这非常重要,如果你还没有准备好自动化回归测试,那么请在重构之前先搭建好测试环境。
    • 努力把代码的重构安排在较小的开发周期内。
    • 尽量把更改独立化,方便查找问题。
    • 确保测试计划包含了所有的回归、功能、负载、性能和用户验收测试。
    • 在开始重构之前,花时间弄清楚复杂的代码逻辑。
    • 在需要时利用设计模式,不要为了用而用,必须要充分的理由。

    无独有偶,技术专家McConnell在“代码大全”中也提到了安全重构的措施。

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

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

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

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

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

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

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

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

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

    不适合重构的情况包括:

    不要把重构当做先写后改的代名词——重构最大的问题在于被滥用。程序员们有时会说自己是在重构,而实际上他们所完成的工作仅仅是对无法运行的代码修 修补补,希望能够程序跑起来。重构的含义是在不影响程序行为的前提下改进可运行的代码。那些修补破烂代码的程序员们不是在重构,而是在拼凑代码。

    避免用重构代替重写——有时,代码所需要的不是细微修改,而是直接一脚踢出门外,这样你就可以全部重新开始。如果发现自己处于大规模的重构之中,就应该问问自己是否应该把这部分代码推到重来,重新设计,重新开发。

    Kent Beck认为,重构中面临最大的挑战就是如何做到循序渐进,循序渐进指的是如何将工作分解为可控的步骤,并且每个步骤都易于管理。重构步伐过快会导致不稳定代码的出现。此外,想得越多,越是谨慎反而会严重减慢重构的步伐。

    正如许多与我结对编程的伙伴都会告诉你的那样,我有一个非常不招人喜欢的习惯:在重构时总会说“不要再想啦”。我知道这并不是我真正要说的,因为我不可能去故意表达这个意思,但是直到现在,我才有机会可以给出一个更好的解释。

    垂直重构是指调整方法或代码块在调用堆栈中的上下顺序,然而水平重构则指的是在类似于同级别的对象间所做的调整。依Kent所述,重构时应避免同时做上述两种调整。

    当需要重构具有多重调用或是多重实现的对象时,就要额外小心,并且重新回到垂直和水平方法,将这两者操作分开进行,并且要时刻注意代码重构的深度。

    Kent Beck认为比较好的一个办法就是使用索引卡(Index Cards):

    在电脑旁放置索引卡会帮助我保持专注。当我在处理水平重构时突然意识到还可以做垂直重构时,我会迅速记在索引卡上,然后马上回到刚才正在进行的工作 中。这种方法不仅可以使我在进行下一步工作前,有效地先将手头的工作结束,同时,又不会导致某些好点子被遗忘。方法之好用,整个过程感觉就像是在做冥想, 技能感受到自己的呼吸,又不会被完全自我的意识所牵绊。

    崔康 热情的技术探索者,资深软件工程师,InfoQ编辑,从事企业级Web应用的相关工作,关注性能优化、Web技术、浏览器等领域。

  • 相关阅读:
    微软职位内部推荐-Software Engineer II
    微软职位内部推荐-Senior Software Engineer
    Linux日期时间显示输出
    Redis性能优化
    Can't use Subversion command line client: svn
    redis常用性能分析命令
    Linux下配置tomcat + apr + native应对高并发
    Tomcat7并发和线程数
    mongodb常用命令小结
    Spring MVC @PathVariable被截断
  • 原文地址:https://www.cnblogs.com/ocean2000/p/2773287.html
Copyright © 2020-2023  润新知