如何避免加班和错过最后期限

很多软件工程师，包括我自己，都对代码质量充满热情。虽然在完成工作的同时，努力打造一个结构良好的代码库可能会耗费大量的时间和精力。我一直在寻找既能实现这两个目标，又不会做出重大牺牲的方法。请继续保持现状。

• 不要投入时间
• 使用正确的技术
• 记住范围
• 什么时候最好不要重构

马丁·福勒 (Martin Fowler)认为，重构是“对软件内部结构进行的改变，使其更易于理解，并且在不改变其可观察行为的情况下，修改成本更低”。换句话说，这种改变追求的目标是编写结构良好、可读性强的代码，在执行相同的操作的同时，更自然地接受新的变化。

顺便说一句，他提到的不变的可观察行为涵盖了两个方向。显然，之后一切都应该以相同的方式工作。同时，我们也无需在此基础上进行任何错误修复或性能改进。这可能是一个令人愉快的副作用，但并非重构的最终目的。最好不要一举两得，以降低出现新错误的可能性。最终，这可以节省一些调试时间。

即使你当前的任务是优化，这条原则也适用。冷酷地改进代码结构，不考虑性能，但要考虑可读性。然后，在理解更深层次之后，再开始优化。这通常比直接跳到结构糟糕的代码上花费更少的时间。

不要投入时间

我知道，这听起来适得其反。

然而，关键在于，专门花时间进行代码重构通常听起来像个笑话。除非这是你自己的一个业余项目，否则你很难说服你的经理。他们会有一个坚实的论据——数字。这完全合理，谁愿意为更漂亮的代码付费，而软件却一成不变呢？正如我在开头所说，重构不一定会给产品带来任何可计费的价值。性能不会大幅提升，bug也不会消失。

好消息是，如果重构只是你日常工作的一部分，你无需说服任何人。就像使用终端、在 Git 中提交代码、阅读电子邮件等等一样。这些活动可能只是你工作流程中的一部分，因此没有人真正担心在这些活动上花费的时间。就像艺术家在绘画前准备画布一样，重构意味着软件工程师在编辑代码之前准备代码——这是工作中很自然的一部分。

然而，你最初的小规模重构不应该突然发展成为持续两周的马拉松，并且代码库也会遭到破坏。

持续功能软件至关重要，因为它能够完全控制整个流程。你基本上可以随时停止重构，并且 离开大楼切换到实际任务。

使用正确的技术

我了解到，基本上有两个组成部分构成了受控重构：小规模的转变和快速的测试，在每次改变之后执行。

循序渐进的小规模转换对于防止出现问题状态非常有帮助。只需修改几行代码，错误就可能相对少发生。

理想情况下，步骤应该尽可能小，例如重命名变量或将代码块提取到函数中。可以考虑使用自动化工具，例如VS Code 中的“重命名符号”命令，因为它们通常比手动编辑更不容易出错。

这些改变本身可能意义不大。但由于每一步都是为了改进代码结构，最终都会得到令人满意的结果。不妨把它想象成一盘棋——连贯的策略才能取胜。即使单个动作可能显得被动甚至奇怪，但这些动作结合起来却威力无穷。

即使出现问题，也可以轻松地后退一步再试一次。因此，请慷慨地将这些步骤提交到版本控制系统（例如 git）中。这些步骤就是检查点。请使用有意义的提交信息，例如“将验证逻辑提取到函数中”，而不是像“重构”这样泛泛而谈。如果出现问题，您可以轻松地在这些提交之间导航。如果一开始就出了问题，但您在十几次提交之后才注意到？别担心，试试git bisect 吧。也不用担心 git 历史记录混乱，在合并到主分支之前将其压缩即可。

无论变更多么精确，仅凭静态代码分析，您都无法完全确定一切是否仍然以相同的方式运行。我们毕竟是人，不是吗？理想情况下，每次变更后都要确保代码库的健康状况。因此，快速且易于运行的测试必不可少。理想情况下，系统会针对您当前正在开发的那部分代码执行自动化测试。缺少自动化测试？或许现在正是添加一些自动化测试的好时机。否则，请尝试找到阻力最小的途径，手动测试您的系统。

以上是对受控重构技术的简要概述。我只是想分享我建议中的核心概念，而非旨在提供定义指南。如果您想深入了解，我建议您从Martin Fowler 的《重构：改进现有代码的设计》一书开始。我从中汲取了不少灵感，并运用到我的日常工作中，这启发了我写下你正在阅读的这篇文章。

记住范围

重构过度是很常见但可以理解的。使用我们刚才讨论的技巧，你可能会很容易地跟着节奏走，而忘记真正的目标。

在我的工作流程中，我通常会尝试通过提出以下问题来评估：我的代码是否足够好，可以开始实际实现？

追求完美的过程总是有变化的。但最终能否实现这一点却令人怀疑。此外，无论你曾经多么接近完美，软件在其生命周期内通常都会不断变化。随着时间的推移和后续的修复，很有可能从完美匹配转变为“为什么要那样选择！？”的反应。那么，你为什么要在这上面浪费那么多宝贵的时间呢？你或许应该好好考虑一下帕累托原则。

别误会我的意思。我不鼓励你仓促行事，不考虑质量。重构绝对值得，它能提高开发质量和速度。不过，追求好比追求最好。重构代码时要着眼于未来，但主要要关注当前。考虑边缘情况，但不要试图掩盖不切实际的情况。遵循范式，但更注重可读性。保持你自己的编码风格，但不要让它左右你。

什么时候最好不要重构

最后，从节省时间的角度来看，还有什么比直接跳过整个过程更好的呢？

但作为一名优秀的工程师，你或许希望有一个通过的好理由。

我认为经验法则是，重构工作代码而不以利用它为目的可能是浪费时间。

时不时地，你可能会因为这样或那样的原因，偶然发现一些有问题的代码。尽管这些代码与你当前的工作无关，但你很容易就会忍不住去改进它。尤其是当缺陷显而易见的时候。

既然如此，最好还是赶紧行动吧。不过，我得说，我通常有一种不祥的预感，不该对这样的代码库置之不理。有时，这种不祥的预感会占上风。我抱着快速、低效的改进想法，一头扎进去。然后，我开始注意到它离实际工作有多远，于是后悔地撤消了我的更改。比我聪明一点，避免这样的陷阱。这或许能为你节省不少时间，避免后续的热修复工作。

如何避免加班和错过截止日期，实现重构？无缝融入日常工作，保持良好的纪律，并务实的质量，是我目前为止找到的答案。

希望它们能帮助您提升开发体验。归根结底，这才是构建事物时最重要的。请记住，这些工作流程会不断发展——这是一个持续的过程，不要急于一夜之间就完善它。

我一直在寻找更好的方法，欢迎在评论区分享你的经验。当然，你也可以挑战我的方法。

封面照片的版权归属于Unsplash 上的Naja Bertolt Jensen。

首先要特别感谢@josefine ，是他让这段文字成为现实。