重构与前端不正确的数据模型和业务逻辑紧密耦合的活动系统。

Question

场景

这是我曾经不得不维护的一个项目。在阅读了“遗产代码”( Legacy Code )的有效工作之后，我开始思考，如果必须的话，我将如何在生活环境中重构这个系统(谢天谢地，我没有)。

该系统是一个遗留系统，没有文档，而且耦合非常紧密。数据库关系被错误地建模--也就是说，意味着多对一的对象被映射为一对一。使用“复制”允许“伪多对一”关系。业务逻辑仅在前端存储为JavaScript。数据与表示数据紧密耦合。

例如，如果没有Table对象，则无法存在问题对象。数据库有一个表调用"TableCell“来存储每个单元格的内联CSS，该单元格被映射成一对一的”问题“对象。

该系统是一个可怕的混乱，最终导致数据丢失和彻底重写的结果。该项目总共约350 000 LOC。

顺便提一句，系统被重写(或需要重构)的原因是它将暴露在互联网上，但我们能够使用Chrome Debugger修改业务逻辑来提升角色、注入代码和执行各种不想要的功能。

问题

这本书列举了逻辑放在中间层的例子。然而，当业务逻辑放在前端时会发生什么呢？在我看来，重构过程必须这样做：

1. 重构前端JavaScript以理解业务逻辑
2. 重构中间层以包含验证。
3. 重构数据库以解耦数据模型
4. 迁移数据
5. 重构中间层以解耦数据模型。
6. 重构前端以反映数据模型中的变化。

我读过重新分解垃圾和保持理智的技术？，它很有帮助，但是它并没有解决对于这个特定场景应该进行重构的顺序。这个过程似乎增加了大量的冗余，因为前端和中间层在实时系统中被重构了两次。

• 在保持系统正常运行的同时，有什么更有效的方法来重构这样的系统？

Answer 1

这与效率无关，而在于维护一个有效的系统。我喜欢把重构比作爬山。在下一个安全装置就位之前，永远不要移除先前的安全装置。是的，这很辛苦。是的，这似乎需要更长的时间，但任何错误的后果都要小得多。

此外，您通常希望考虑从垂直切片的角度进行重构。最低限度地改进所有层次中的一小部分。例如，与其一次处理整个数据库，不如选择一个表，甚至一个字段，然后遍历所有六个步骤，然后对另一个表重复。你每一次都会学到一些东西，这会使你以后的工作更容易，所以你的反馈周期要尽可能短。

作为一种副作用，短期周期可以让管理层更容易买进。“还记得我的更改在多大程度上加快了发票页面的速度吗?我想对购物车做同样的事情，这也会使您想要的这个新特性更快地添加，并且更健壮。”

Answer 2

您所讨论的场景(以及有效地使用遗留代码)可能不允许您遵循如此长期的计划。很高兴知道您想去哪里，但通常在一个活动的系统中，大多数重构都是在为特定bug修复或新特性服务的小步骤中进行的。

因此，重构的顺序在很大程度上取决于哪些业务需求具有足够高的优先级来工作。然而，对于您所做的每一个故事，您将不得不决定要进行多少重构以及如何处理它，您很可能还可以忽略一些非业务驱动的重构。

当你有选择的时候，你会给出最高的(但不是绝对的)优先级来不破坏东西，而第二优先是让系统的碎片被测试。这两种设计都比清洁设计具有更高的优先级，因为如果系统正在测试，您可以更有效地清理设计。

对于您的具体示例，很难预先预测您最终将进行重构的顺序。我的猜测是，它主要是从UI中下来的--一旦UI通过更合理的API处理中间层，您可能会将业务逻辑与数据库分离得更远，以便重构DB并迁移数据。希望到那时，更改的数据模型将不会在UI中可见，也不会需要UI更改。

但是，这个过程可能会在某种程度上与应用程序的不同部分并行进行，在某些情况下，可能会以不同的顺序结束。

重构一个活动系统通常是一个机会主义和自下而上的过程，无法事先知道订单最终会是什么。