如何以正确的方式进行重构

  

        重构对于软件产品的质量至关重要。没有其他办法了。您可以使用适当的软件范例，通过适当的应用程序设计来避免或推迟大规模重构。尽管如此，您永远无法完全减轻重构的需求。

        这有多种原因：

1. 要求变更
2. 新技术
3. 缩放
4. 原型制作
5. 截止日期
6. 软件设计中的错误抽象和错误

  如何引入重构？

         您可以在不注意管理的情况下在常规任务 (scrum) 中进行小的重构，但情况并非总是如此。您还可以进行一些更重要的重构，作为下一个项目的先决条件。最难的是代码中难以修复的问题，慢慢侵蚀团队中的士气，但很难卖给你的项目经理。在这个“难以销售”的类别中，通常是与数据库模型 (ORM)、可空性问题相关的更改，或者可能只是删除了一些不正确的抽象。

        我经常期望我会在空闲时间解决与“不可销售的重构”相关的问题。恐怕我不得不不同意这一点。它仍然是代码的改进，您应该在工作时间进行。我这样做不是为了好玩，而是为了解决一个真正的痛点。请注意并避免陷入这个空闲时间重构陷阱。您唯一的选择是提供统计数据并说服其他人您将通过进行重构来节省大量时间或防止关键错误。

我们需要提供新功能。以后有时间重构。

        不，以后不会了。是什么让你相信以后会有时间？这是领导者最常使用的谎言。根据我的经验，这在 100% 的情况下都是谎言。此外，截止日期从未像提出的那样严格。我并不是说你不应该在最后期限前完成。更重要的是对问题保持透明并了解您的极限。如果你需要偷工减料，你应该说不可能满足这个最后期限。

那么如何在重构的同时满足最后期限呢？

        在我看来，这个问题是软件开发中最具挑战性的问题之一。答案不是“更加努力”的方法。通过大量练习，我学会了区分我需要立即完成的工作和我可以在较小的步骤中完成的工作。说你稍后会做某事（不考虑步骤）是不正确的，因为你通常不会。没有时间了。

       我总是尝试将代码中的复杂问题分成我可以处理的较小问题。也许您需要摆脱糟糕的抽象或限制可空性，以便您可以从具体的类、模块或文件开始。有大量合并请求并浪费队友的精力进行审查是不好的做法。在小型合并请求中执行此操作。如果您为每个有问题的类创建一个单独的类，这不是问题。与与新功能代码混合时相比，审查要容易得多。

扼杀者模式

        重写整个功能可能是一个坏主意。这正是扼杀者模式试图解决的问题。它是关于创建具有部分功能的新解决方案并逐渐迁移其余部分。

      您在这里唯一需要注意的事情（期待实际功能）是与团队正确沟通您的意图。当你引入第三种方法来解决同样的问题时，它很快就会出错，所以要保持透明。

      我可能会更深入，但我认为这会使这篇文章变得多余。如果您有动力开始新的重大重构，我想警告您。为自己设定一个时间限制。它通过后，您应该决定完成您开始的工作需要多长时间。当您不后退一步时，沉浸在重构的深度中并不难。有时我会丢弃我为保持合并请求的范围可管理所做的部分更改。有时我什至当我看到它是错误的方式时，我什至扔掉了整个 MR。

      没关系，因为这就是获得经验的过程。

七爪网http://www.7claw.com/