大多数客户希望他们的应用程序能够快速、经济、可靠地开发。然而，在追逐时间和金钱的过程中，质量往往被放在一边，一些提高质量的活动被搁置起来。
例如，重构就属于这类活动，而且似乎没有测试那么具体。客户会提出一个合理的问题："如果它能工作，我们为什么要重构它？"尽管如此，代码清理的必要性可能并不总是很明显。
在这篇文章中，我们介绍了代码重构的话题，并讨论了这个过程的价值。
内容。
- 什么是代码重构？
- 为什么你的应用程序需要重构
- 技术债务的后果
- 什么时候应该考虑重构
- 技巧和窍门
- 底线
代码重构是对应用程序代码进行编辑和清理的过程，它可以优化其内部结构，但不改变其外部行为和功能。尽管如此，这仍然是任何项目开发的一个固有部分。然而，对于外部观察者来说，代码重构的必要性可能并不明显。
还是很好奇为什么代码重构如此重要？有一些主要的原因需要在你的项目中加入这项活动。
可维护性和可扩展性
代码重构的主要目标是使代码更加可维护和可扩展。添加到应用程序中的更新和升级是一个持续的、必不可少的过程。所以现有的代码应该使这个过程成为可能。例如，在设计最初的架构时可能没有考虑到一些功能的整合，所以新的功能可能需要在整个开发方法和代码中也进行这些改变。
总的来说，在添加新功能之前回顾和整理当前的代码，不仅可以提高应用程序本身的质量，而且可以使未来的开发者更容易在源代码的基础上进行开发。
此外，当代码库无序且构建效率低下时，开发人员会怀疑是否会做出任何改变。相反，组织良好、整洁的代码会激励开发者保持秩序并增加改进。
破窗的比喻很适合这种情况。一座窗户破损的建筑看起来没有人关心它。所以其他的人就不再关心了。他们允许更多的窗户被打破。最终，他们主动打破了这些窗户。他们用涂鸦掠夺外墙，让垃圾堆积。一扇破窗就开始了腐烂的过程。
因此，最好从一开始就防止任何 "破窗"。
可读性
这个优点与前一个优点紧密相连。易于阅读的代码可以减少开发人员对其理解的努力。此外，这样的代码重构使质量保证和错误识别过程更加顺畅。它确实不能消除错误，但这有助于在未来防止它们。
性能
代码重构的另一个潜在目的是提高性能。因此，重构可以使一个应用程序执行得更快或使用更少的服务器容量。这是代码重构后对终端用户来说可能是真正有形的好处。
节省成本
从长远来看，重构活动应该根据上面注意到的好处而导致成本的降低。重构促进了可重复使用的设计元素的出现，这些元素在未来可能会被简单地用于新功能。结构良好和有组织的代码不需要太多的时间进行知识转移，如果继续开发或由另一个开发者支持的话。此外，代码重构有利于预防错误，这意味着节省时间和成本。
缺乏重构会导致技术债务的积累（也被称为技术或代码损失）--当开发团队采取行动来加速交付某项功能或项目，而后来需要重构时，就会产生这种结果。换句话说，这是优先于完美代码的快速交付的结果。你不关心沿途的小问题的时间越长，它们就越有可能发展成主要的复杂问题。
随着时间的推移，技术债务在系统中不断积累，有几个主要的高级后果。
因此，迟早要还清债务，以使一个应用程序能够继续工作和改进。
尽管重构的好处可能只出现在长远的角度，但为了不增加技术债务，应该尽快考虑。
由于应用程序的功能并不取决于重构，而只取决于代码的变化，所以开发者本人或审查代码的技术负责人应该定义何时以及哪些重构是必要的。如果注意到所谓的 "代码气味"，重构通常是不可替代的，这意味着无视基本的设计原则，代码设计中的弱点，使用胶布，这些都会导致开发速度减慢，并在未来出现错误或失败的风险增长。
以下几点可能会触发重构活动。
- 软件开发完成后，代码难以阅读，过于笨重。
- 在一个应用程序中经常使用重复的代码部分。
- 应该增加现有应用程序的机会。
- 在代码中使用了很多有特色的条件运算符。
与 "闻代码 "相反，专家们使用 "干净的代码 "的定义，这是任何质量改进，包括重构的最终目标。从这个角度考虑，如果 "干净的代码 "出现以下缺失的特征，就可以考虑进行重构。
- 代码的逻辑是直截了当的，这使得bug难以隐藏。
- 依赖性最小，这就简化了维护。
- 性能接近于最佳，没有不必要的优化。
- 干净的代码不包含重复的内容，并尽量减少实体的数量，如类、方法、函数等等。
一般来说，每次都可以考虑重构，为应用程序的开发部分添加任何改进或新功能。
这听起来很奇怪，但另一个考虑重构的适当时机是在生产中部署和在真实用户上测试一个应用程序后，当它明确了应用程序的性能和生产力是否足够时。此外，在产品交付给市场后，终于没有严格的最后期限了，开发团队可以深呼吸一下，拿出一些时间来 "整理内务"。
当重构是不必要的
可能会出现这样的情况：一个应用程序需要从一开始就完全重写，而简单地从头开始，这样重构就没有必要了，这样会更节省成本和时间。这种情况可能发生在代码完全不可读、无法维护或扩展新功能、过于过时的时候。换句话说，重构没有及时进行，导致了这些关键问题，现在看来，致力于纠正失败和进一步重构的努力超过了致力于应用程序全面重新开发的努力。在这种情况下，代码重构的意义是很难高估的。
另一种情况是，如果开发有一些严格的最后期限和市场交付时间，推迟重构是明智的。重构可能就像进入了传说中的兔子洞。一旦你开始，它可能需要比预期更多的时间。尽管如此，一旦最后期限过去，就应该重新考虑代码重构的可能性。
如果你的应用程序不打算延期，可能不值得重构。另一方面，如果代码是为了进一步使用，以后总会有一些功能需要添加或更新，所以把投资放在重构上是有意义的。
有一些最佳实践可以帮助使重构变得合理和有效。
1）在添加新功能之前就应该考虑重构。一旦出现添加新功能或更新的要求，对现有代码进行重构是个好主意。当然，这将延长项目的时间线，但这也将减少你在未来要处理的技术债务的数量。
2）重构应该被仔细计划和估计。评估所需的工作范围，并对这项工作进行合理的估计，以坚持项目的最后期限，这是非常重要的。代码重构可能仍然会发现一些不可预测的问题，这将需要比预期更长的时间，所以最好在估计中多加一个缓冲时间，以免破坏对应用程序交付计划的期望。
3）重构应该伴随着单元测试。重构的目的不仅是为了清理代码，而且是为了维护系统的良好运行。因此，为了检查是否有问题，单元测试是必不可少的。由于编写单元测试也需要时间，所以最好在项目的一开始就引入单元测试。
4)QA团队应该参与到重构过程中。由于重构不应该，但仍然可能影响应用程序的外部行为，这与测试团队参与执行修改后的应用程序部分和连接部分的回归测试有关。
作为重构工作的一部分，单元测试和回归测试都应该被执行。这将确保解决方案的功能不受任何影响。
重构是每个项目的一个重要组成部分。为了更容易理解它的必要性，人们可以把代码重构看作是保持办公桌的清洁和有序。当你保持秩序时，你的压力就会减少，因为所有的东西都很容易找到和操作。反之，如果办公桌上有奇怪的东西，就会导致环境的混乱和压力的增加。这就是代码重构的意义。
对于书面代码也是如此。牢记定期清理代码的必要性，你会得到一个更高质量的应用程序和一个更平和有效的工作环境。
原文发表于sumatosoft.com
