缩短重构所花时间的三个贴士

译文
开发 前端
最近,我不得不处理一个难以维护和扩展的旧代码库。本文介绍我和我的团队如何决定处理维护以及我们为缩短重构时间而实施的最佳实践。

​译者 | 布加迪

审校 | 孙淑娟

代码重构简介

代码重构指在不更改代码功能的情况下,重构之前编写的代码。重构并不意味着添加新功能或重写代码来修复任何类型的错误。

进行重构有几个好处,包括:

  • 提升性能
  • 提高代码覆盖率
  • 提高代码可读性
  • 更深入地理解代码库
  • 更易于扩展、维护和升级
  • 查找错误或漏洞

通常每次针对一小块代码进行重构,而不是直接处理庞大的代码库。

别忘记在重构之前应该有写得很好的测试用例。测试用例有助于确保刚修改的代码并不破坏现有功能。时不时测试应用程序的整体代码覆盖率也是一个好的做法。可能没有100%的代码覆盖率,但工程师应该始终旨在接近100%的代码覆盖率。

下图显示了重构过程通常是如何进行的。

我想分享自己的故事,讲述我和我的团队过去如何处理重构。五年来,我从事过诸多项目。有一个项目有非常旧的代码库,维护和扩展起来有难度。我们遇到了连添加一个小功能都很难的情况。这里存在很多的代码冗余。我们与项目CTO和产品负责人讨论了这个问题,一致同意在添加任何新功能之前先执行重构。由于没有编写测试用例,因此无法直接跳过去修改代码。

初创公司什么时候应考虑重构?

当我们的团队决定是否应该重构时,我们考虑在以下开发者工作流程步骤进行重构:

  • 在代码审查期间

代码审查又叫同行代码审查,是代码审查人员在接受合并请求(PR)之前检查代码库的过程。这是确保代码无错误、高效、遵循最佳编码约定的好方法。

将每个团队成员添加为代码审查员帮助我们及早发现了错误,并在整个公司保持一致的编码风格,因为合并请求只有在得到所有代码审查员的批准后才会合并。

  • 添加任何更新或新功能后

考虑重构的方法之一是在添加新功能或对应用程序进行任何更改之前。这么做将有助于改进应用程序的代码库,而且将来的工程师使用起来会更有效率。此外,工程师应定期检查项目是否具有良好的代码覆盖率。

由于应用程序使用Ruby on Rails编写,我们使用了Rubocop(https://rubocop.org/?ref=hackernoon.com),这是一种Ruby代码样式检查器(linter)和格式化工具。Rubocop不仅报告了代码库中的问题,还自动修复了一些问题。

  • 推出产品后

大多数初创公司通常旨在快速推出产品。这个过程中可能有一些代码不符合高质量代码标准。因此,一旦产品面市,重构代码库也是使代码更高效、更稳健的好方法。这么做不会影响业务,因为产品已经在市场上推出了。

由于产品已经投放市场,我们的团队使用这种方法进行重构。我们致力于重构应用程序代码库的大部分代码,以提高代码可读性并降低复杂性。

初创公司在进行重构时可能会遇到哪些问题?

初创公司在进行重构时面临许多挑战。我们在这么做的过程中就遇到了很多问题:

  • 耗费时间

有时,重构花费的时间比预期的长。初创公司经常需要添加新功能,更专注于尽早将产品投放市场。初创公司需要聘请专门的开发人员,或推迟开发新功能,执行代码重构。

我们在没有任何测试用例的情况下处理遗留代码库,因此我们花费的时间比预期的长。

  • 引入错误的风险

在进行代码重构时,始终有可能引入错误。工程师在正确重构代码之前,需要了解代码逻辑。

这个过程帮助我们跟踪试运行环境和生产环境中的错误。

  • 复杂性

重构以前编写的代码是一项复杂的任务。涉及多个开发人员或自由职业者时,就变得更为复杂。首先,您需要了解代码库,检查是否编写了适当的测试用例。如果缺少任何测试用例,需要添加。了解编写的代码、编写测试用例,并确保刚修改的代码不会破坏任何功能,这使得重构过程很复杂。

成功重构的流程

经过几次讨论后,我们的团队决定在处理重构时遵循以下步骤:

  • 添加测试用例。
  • 使用Stepsize,直接从编辑器将技术问题添加到我们的项目管理工具。
  • 将代码部署到试运行环境,等它通过所有测试用例。
  • 让客户审查试运行环境中的变更,确保没有受到影响。
  • 定期监控Bugsnag这个错误监控软件,查看Stepsize问题。
  • 将代码更新部署到主分支,等它通过所有测试用例。最后,合并主分支,并部署到生产环境。
  • 从上往下重复该过程。

如何缩短重构所花的时间?

我们遵循以下几个策略来避免或缩短重构所花的时间:

  • 每隔一个sprint就有重构周

缩短重构时间的方法之一是,每隔一个迭代开发周期(sprint)安排重构周。这么做将有助于在代码库的问题导致严重问题之前发现这些问题,保证将来不会有任何技术债务。

使用这种方法,我们的团队减少了大部分重构时间。我们开始编写缺失的测试用例,这帮助我们提高了整个代码覆盖率。

总体而言,每隔一个sprint安排重构周是为了缩短花费在批量重构上的时间,防止技术债务出现。

  • 在编辑器中跟踪代码库问题

开发人员将大部分时间花在代码编辑器上。因此,标记这些问题的最佳地方是在编辑器中。

Stepsize VSCode和JetBrains扩展件有助于全面了解开发人员可以解决的代码库问题,避免造成大量重构和技术债务,并为开发人员节省大量时间。

您可以将技术问题与您的代码关联起来,并在Jira、Asana、Azure DevOps和Linear等不同的项目管理工具中查看。

  • 定期讨论技术债务

在每次编码sprint之后,定期讨论技术债务始终很棒。团队可以讨论什么是正确的,什么是错误的。这样一来,工程师可以获得必要的反馈。

在编码sprint后,我们开始简短地讨论技术债务。在过去花费大量时间进行重构、了解造成的严重后果之后,产品负责人也参与到技术债务讨论。这使产品负责人意识到取得的成果,以及在项目受到巨大影响之前需要处理的问题。

原文标题:Reducing Time Spent on Refactoring 3 Tips from a Dev​,作者:Alex Omeyer​

责任编辑:华轩 来源: 51CTO
相关推荐

2023-06-26 08:06:39

重构代码冗余

2015-03-24 10:54:04

Apple Watch

2020-11-24 09:00:00

物联网安全技术

2011-10-25 18:35:47

Qcon支付宝程立

2018-12-24 09:00:00

测试工具Flood Eleme

2023-04-26 11:14:11

IT领导者远程工作

2023-02-07 16:21:37

时间序列列数据集

2017-01-06 10:07:39

Linuxwindowsatime

2022-05-02 17:52:53

Python编程语言

2020-06-11 09:00:27

SDN网络架构网络

2017-09-26 09:12:26

公共云存储服务

2023-02-21 17:04:31

2022-03-01 17:26:35

华为数字化

2017-07-20 10:46:57

网页CDN加速缓存

2022-06-30 09:01:00

嵌入式软件技巧

2018-02-25 07:23:23

2010-09-02 16:46:52

SOAP协议

2011-12-20 10:41:36

程序员

2018-03-18 08:02:16

数据中心操作运营安全性

2020-02-26 08:00:56

管理工具云平台管理平台
点赞
收藏

51CTO技术栈公众号