关于代码重构你应该知道的内容-阿里云开发者社区

关于代码重构你应该知道的内容

2022-09-27 125

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 关于代码重构你应该知道的内容

1 什么叫做重构

重构是在不改变软件可观察行为的前提下改善其内部结构, 重构的本质就是在代码写好之后改进它的设计

在这里插入图片描述

应该怎样安排重构时间表。是不是应该每两个月就专门安排两个星期来进行重构呢？

作者提出的意见是：几乎任何情况下都反对专门拨出时间进行重构。重构本来就不是一件应该特别拨出时间来做的事情，重构应该随时随地进行。不应该为重构而重构，你之所以重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好

第一次做某件事时只管去做；第二次做类似的事会产生方案，但无论如何还是可以去做；第三次再做类似的事，你就应该重构

简单理解：事不过三，三则重构

最常见的重构时机就是我想给软件添加 新特性 的时候。此时，重构的直接原因往往是为了帮助我理解需要修改的代码 - 这些代码可能是别人写的，也可能是我自己写的
无论何时，只要我想 理解代码所做的事，我就会问自己：是否能够对这段代码进行重构，使我能更快地理解它。然后我就会重构
之所以这么做，部分原因是为了让我 下次再看 这段代码时容易理解。但最主要的原因是如果再前进过程中把 代码结构理清，我就可以从中理解更多东西

调试过程中运用重构，多半是为了让代码更具有可读性

有时候你根本 不应该重构，例如当你应该重新编写所有代码的时候。有时候既有代码 实在太混乱，重构它还不如 重新写 一个来的简单
重写 (而非重构)的一个清楚讯号就是：现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本 无法稳定运作。记住，重构之前，代码必须起码能够大部分情况下正常运作
另外在项目已经最后期限，你也应该避免重构。在此时机，从重构过程赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经 为时晚矣
如果项目已经非常接近最后期限，你不应该再 分心于重构，因为已经没有时间了。不过多个项目经验显示：重构的确能够提升生产力。如果最后你没有足够时间，通常就表示你其实 早就该进行重构

重构肩负一项特殊使命：它和设计彼此互补。初学编程时候，我埋头就写程序，浑浑噩噩地进行开发。然后很快我便发现：事先做好设计可以让我节省返工的高昂成本
有一种观点认为：重构可以取代预先设计。这意思就是你根本不需要做任何设计，只需按照最初想法开始编码，让代码有效运作，然后再将它 重构成型。事实上这种办法真的可行。的确有人这么做，最后获得设计良好的软件。极限编程[Beck，XP]的支持者极力提倡这种办法
尽管如上所言，只运用重构也能收到效果，但这 并不是最有效的途径。是的，就连极限编程的爱好者们也会进行预先设计。关键在于：重构改变了预先设计的角色。如果没有重构，你就必须保证预先做出的设计正确无误，这个压力太大了。

如果你选择重构，问题的重点就转变了。你仍然预先设计，但是不必一定找出正确的解决方案。此时的你只需要得到一个足够合理的解决方案就够了

这种转变导致一个重要结果：软件设计向简化 前进了一大步。过去未曾运用重构时，总是力求得到灵活的解决方案。任何一个需求都提心吊胆地猜疑：在系统的有生之年，这个需求会导致怎样的变化？由于 变更设计的代价非常高昂，所以我希望建造一个 足够灵活、足够可靠 的解决方案，所需的成本难以估算
有了重构，你就可以通过一条不同的途径来应对变化带来的风险。你 仍旧需要思考潜在的变化，依旧需要考虑灵活 的解决方案。但是你不必再逐一实现这些解决方案，而是应该问问自己：“把一个简单的解决方案重构成这个灵活的方案有多大的难度？”如果答案是“相当容易”（大多数时候都如此），那么你就只需要实现目前的简单方案就行了
重构可以带来更简单的设计，同时又 不损失灵活性，这也 降低了设计过程的难度，减轻了设计压力。一旦对重构带来的简单性有更多感受，你甚至可以不必再预先思考前述所谓的灵活方案，一旦需要它，你总有足够的信心去重构。是的，当下只管建造可运行的最简化系统，至于灵活而复杂的设计，唔，多数时候你都不会需要它

懒惰是程序员的美德之一，绝不要因为《重构改善既有代码的设计》让你变得勤快

在设计前期使用设计模式常常导致过度工程，良好的程序设计是维持软件开发速度的根本

以重构方式改进软件质量

重构有风险，修改需谨慎

任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员