在复杂的代码库中进行安全更改的简单技术

你接手了 30 万行意大利面条式的代码。现在你该做什么？

大型、未经测试、文档记录不全的代码库很难处理，很难推理。

你无法在复杂的代码库中快速行动。

陷入遗留代码的泥潭

问题是，他们叫你修改代码库！你需要满足新的功能需求，或者修复一些 bug。

也许你决定解决技术债务并重构遗留代码。也许你想在系统为客户生产服务的同时改进其架构。

但任何有价值的改变都会让你走上失败之路😩

假设你想升级你的 ORM 依赖项。你开始着手升级，但很快发现有一些重大变更。所以你需要修改代码库中的一些函数调用。为了方便操作，你决定重构并将它们提取到某个地方，这样就只有一个地方需要修改。但要做到这一点，你需要先调整每个调用……

很快你就会发现自己陷入了流沙：每当你解决一个问题，就会出现另外两个问题。

项目无法再编译了。距离你提交代码已经过去几个小时了。“我还在处理，只需要修复几个问题”这几天你的单口会议就是这么回事……

如果您在这里，那么您并不孤单！

还有一种方法可以避开流沙。我即将教你：Mikado 方法。

以结构化的方式实现有价值的改变

其要点听起来像是常识：

吃掉大象只有一种方法：一次咬一口。

在复杂的代码库中，小的变化很快就会变成大问题。

如果你提前解决这些问题，很可能会碰壁。这会很痛苦，你会迟到，客户和管理层也会不高兴。信任会逐渐消失，而如果没有信任，你很难获得管理层对必要重构的支持。

相反，把大象砍成小块🐘

流程

具体来说，您可以遵循以下Mikado 方法流程：

1. 拿张纸。有时候低技术含量更好。现在就是这样。
2. 设定一个目标。把它写在纸上。把它放在最上面或中间，其实都无所谓。只要留出空间给其他事项就行。
3. 尽量在规定的时间内完成目标。5分钟、10分钟、15分钟，随你便。保持时间相对较短。

• 如果失败了：

  • 撤销你的更改。撤销你在指定时间内所做的更改。这对于重新开始至关重要。
  • 想想你还缺少什么。你需要做哪些改变才能让目标更容易实现？这就是你的子目标。
  • 将其写在纸上并将其附加到您试图实现的目标上。
  • 从 3) 开始制定你的子目标。

• 如果成功：

  • 承诺。你一定会在时间限制结束前完成，没关系，停止计时器。
  • 在纸上检查一下你实现的目标。内心庆祝一下。
  • 从3)开始，并确定下一个未选中的子目标。从Mikado图的叶子节点开始。迭代直到选中了主要目标为止。

真实情况

让我们回到 ORM 依赖项升级。

首先，把目标写在纸上。画两个圆圈。这就是你的主要目标！

你尝试这么做。你升级了依赖项，却发现项目无法再编译了。该死，你之前应该看看更新日志！

好的，您阅读了变更日志，并了解到需要更改一些调用。坦白说，对于一个时间盒来说，更改这么多可不是闹着玩的！

撤销你的更改。真的。撤销它。这很重要。🔥

然后，写下之前需要做的事情。

如何在短时间内更改几个调用？很简单：提取调用，这样就不用改太多地方了。这样升级本身就很快！

重新开始。尝试在时间框内提取第一个方法。

希望只有几个调用，而且它们看起来都差不多。你可以在几分钟内完成这项任务。恭喜！

投入工作，检查子目标，然后给自己鼓劲。你离主要目标又近了一步。

现在尝试接听另一个电话。你开始接听了，但不如上一个电话顺利。

几分钟后，停下来思考一下。还缺少什么？怎样才能让这个改变更容易实现，就像之前那样？

也许您首先需要让每个呼叫看起来都一样。

恢复你的更改。再说一遍。我是认真的。

然后写下新的子目标。

从一片叶子开始，不断重复。

当每个子目标都得到检查后，实现目标应该会很容易。最终，你会让主目标变得容易。

那么，就这么做吧。升级你的 ORM 依赖项。

恭喜！你刚刚实现了一项雄心勃勃的变革，而没有陷入代码库的泥潭。

掌握 Mikado 方法的 3 条建议

1. 缩短你的时间盒。这样，撤销更改会更容易。这是避免沉没成本谬误的关键一步。我发现10 分钟是一个务实的折衷方案。
2. 勾选目标后提交。这是一个检查点，让你更接近主要目标。这意味着你可以随时停止，提交 PR 并提交改进。你可能还没有完成任务，但你让它变得更容易了。
3. 当你开始一个雄心勃勃的重构时，可以使用这个。循序渐进并保持代码处于可交付状态，可以带来令人难以置信的生产力。

为什么叫“天皇”呢？

这是对Mikado 拾棍游戏的引用。

您要删除的Stick是您的 ORM 依赖项升级。

它与许多其他东西纠缠在一起：需要进行烦人的依赖关系和调整，以使代码仍然有效。

策略是先把容易拿的棍子拿下来。也就是那些没有缠结的棍子。慢慢地，解开你的棍子。直到你拿到它而不弄坏任何东西🎉

经过一些练习，你就会变得擅长它。

您将成为更高效的开发人员！