译者|布加迪评论家|孙淑娟代码重构简介代码重构是指在不改变代码功能的情况下，对以前编写的代码进行重构。重构并不意味着添加新功能或重写代码来修复任何类型的错误。重构有几个好处，包括：提高性能提高代码覆盖率提高代码可读性更好地理解代码库更容易扩展、维护和升级查找错误或漏洞通常重构是一次针对一小段代码完成的，而不是直接处理拥有庞大的代码库。不要忘记在重构之前应该有编写良好的测试用例。测试用例有助于确保刚刚修改的代码不会破坏现有功能。不时测试应用程序的整体代码覆盖率也是一种很好的做法。可能没有100%的代码覆盖率，但工程师应该始终以接近100%的代码覆盖率为目标。下图显示了重构过程通常是如何工作的。我想分享我自己的故事，讲述我和我的团队过去是如何处理重构的。在过去的五年里，我参与了许多项目。一个项目有一个非常陈旧的代码库，难以维护和扩展。我们遇到过很难添加一个小功能的情况。这里有很多代码冗余。我们与项目CTO和产品负责人讨论了这个问题，并同意在添加任何新功能之前执行重构。由于没有编写测试用例，因此无法直接进入并修改代码。初创公司什么时候应该考虑重构？当我们的团队决定他们是否应该重构时，我们会考虑在以下开发人员工作流步骤中进行重构：在代码审查期间代码审查，也称为同行代码审查，是代码审查者在接受合并请求(PR)库过程之前审查代码的地方。这是确保您的代码无错误、高效并遵循最佳编码约定的好方法。将每个团队成员添加为代码审阅者有助于我们及早发现错误并在整个公司内保持一致的编码风格，因为合并请求只有在所有代码审阅者批准后才会合并。在添加任何更新或新功能之后考虑重构的方法之一是在添加新功能或对应用程序进行任何更改之前。这样做将有助于改进应用程序的代码库，并提高未来工程师的使用效率。此外，工程师应该定期检查项目是否具有良好的代码覆盖率。由于应用程序是用RubyonRails编写的，我们使用Rubocop(https://rubocop.org/?ref=hackernoon.com)，这是一个Ruby代码风格检查器(linter)和格式化工具。Rubocop不仅会报告代码库中的问题，还会自动修复其中的一些问题。大多数初创公司通常旨在快速推出产品。这个过程中可能会有一些代码不符合高质量代码标准。因此，重构代码库也是让产品上市后代码更高效、更健壮的好方法。这样做不会影响业务，因为该产品已经在市场上销售。由于产品已经上市，我们的团队使用这种方法进行重构。我们致力于重构应用程序的大部分代码库，以提高代码可读性并降低复杂性。初创公司在重构时可能会面临哪些问题？初创公司在重构时面临许多挑战。我们在这样做的时候遇到了很多问题：耗时有时，重构花费的时间比预期的要长。初创公司通常需要添加新功能，并更加专注于尽早将产品推向市场。初创公司需要聘请专门的开发人员，或者延迟开发新功能，并进行代码重构。我们正在处理没有任何测试用例的遗留代码库，因此我们花费的时间比预期的要长。引入错误的风险在进行代码重构时，总是存在引入错误的可能性。工程师需要了解代码逻辑才能正确重构代码。这个过程帮助我们跟踪暂存和生产环境中的错误。复杂性重构以前编写的代码是一项复杂的任务。当涉及多个开发人员或自由职业者时，情况会变得更加复杂。首先，您需要了解代码库，检查您是否编写了正确的测试用例。如果缺少任何测试用例，则需要添加它们。了解您编写的代码，编写测试用例，并确保您刚刚修改的代码没有破坏任何功能，这些都会使重构过程复杂化。成功重构的流程经过多次讨论，我们的团队决定在处理重构时遵循以下步骤：添加测试用例。使用Stepsize，可以直接从编辑器向我们的项目管理工具添加技术问题。将代码部署到暂存环境并等待它通过所有测试用例。让客户审查暂存环境中的更改，以确保它们没有受到影响。定期监控错误监控软件Bugsnag，以查找Stepsize问题。将代码更新部署到master分支，等待它通过所有测试用例。最后，合并主分支并部署到生产环境。从上到下重复这个过程。如何减少花在重构上的时间？我们遵循几种策略来避免或缩短花费在重构上的时间：每隔一个sprint安排一个重构周减少重构时间的一种方法是每隔一个sprint安排一个重构周。这样做将有助于在代码库导致严重问题之前发现问题，确保您将来不会有任何技术债务。使用这种方法，我们的团队减少了大部分重构时间。我们开始编写缺失的测试用例，这有助于我们提高整体代码覆盖率。一般来说，每隔一个sprint安排重构周的目的是为了缩短批量重构的时间，防止出现技术债。在编辑器中跟踪代码库问题开发人员将大部分时间花在代码编辑器上。因此，标记这些问题的最佳位置是在编辑器中。StepsizeVSCode和JetBrains扩展有助于全面了解开发人员可以解决的代码库问题，避免造成大量重构和技术债务，并为开发人员节省大量时间。您可以将技术问题与您的代码相关联，并在Jira、Asana、AzureDevOps和Linear等不同的项目管理工具中查看它们。定期讨论技术债务在每次编码冲刺之后，定期讨论技术债务总是很棒的。团队可以讨论什么是对的，什么是错的。这样，工程师可以获得必要的反馈。在编码冲刺之后，我们开始简短地谈论技术债务。在过去花费大量时间重构并了解严重后果后，产品负责人也参与了技术债务讨论。这使产品负责人了解已经取得的成果，以及在项目受到重大影响之前需要解决的问题。原标题：ReducingTimeSpentonRefactoring3TipsfromaDev，作者：AlexOmeyer
