传统系统中的重构:好与坏的技术退步

Question

当涉及到重构代码时，我注意到了一种奇怪的心态，我不太确定我是如何看待它的。

当前项目概述：

作为现有第三方web应用程序的扩展而使用的web应用程序。第三方应用程序维护客户和供应商之间的日程安排。该扩展允许修改客户请求重新调度的天数/时间，在发生紧急情况时更改当前的计划集，如果无法再签约则更改供应商，并创建适当的记帐文件。就开发而言，团队是按照Scrum的大部分思想来设置的。

该系统是根据许多假定的一次性标准构建的，主要原因是项目的客户不完全了解他们的内部流程(由于内部培训/失误)。我们已经看到了许多领域，那里有基于包含硬编码字符串的检查。

这就引出了这个问题。有一个针对特定供应商的检查(我们可以称它为SomeVendor)，并将检查设置为是否名称包含一些。稍后，当我们获得和失去供应商时，另一个供应商将被添加为SomeOtherVendor。这方面的问题当然是基于包含一些内容的检查。SomeVendor是一个需要检查的特定案例，它们的其他供应商也需要进行类似的检查，并在自己的一组功能中进行分支。在查找这些检查时，我们发现它是针对时间表开发的，可以与供应商相关，但并不总是分配给供应商。用户将在运行时将其关联起来。

客户意识到SomeVendor存在问题，并要求将缺陷放入待办事项中，并已与产品所有者对其进行了优先排序。我发现了这个缺陷，并为有效的SomeVendor供应商开发了一个查找表(如果基于Id的情况下不止一个是有效的)。

有一个中Sprint部署即将到来，所以我去讨论是否有必要将此添加到部署与我的领导。他表示他喜欢这个解决方案，但他问我是否能以一种包含所有需要检查的供应商映射的方式来实现。他还说，这完全是为了当前的问题。

第二天，高级开发人员要求与我合作设计，并继续讨论配置所有供应商，并将其纳入代码库。如前所述，系统对某些供应商进行了解释，因为它们“可以是”某种类型的供应商，但情况并不总是如此。

我们讨论了这一点，即系统只将其解释为可以的，但直到它们在运行时保存时才能确定。我们的建议是将这一点提交给产品所有者，并从项目客户那里获得标准。

我看到了重构到代码基将正确使用这一点的一点，但我觉得它现在已经进入了过度工程的领域。这种感觉主要是由于一个故事/缺陷已经确定和优先与客户，我们已经给出了我们说，我们将做什么，我们将从Sprint计划。这感觉就像我们在偷偷地使用他们不知道自己需要的可交付产品(最近我们和客户已经讨论过了)。

这种类型的重构是应该发生的事情，还是技术上的倒退的迹象？实际上，对于我来说，答案是否具体涉及敏捷并不重要。在我看来，在我看来，团队有一些要求的工作，然后交付一些未达成协议的工作，这似乎很奇怪。

Answer 1

我不明白你有什么具体的问题，但我注意到你的问题中有一些一般性的想法。

如果您正在实现的更改不影响产品的用户权限行为，那么就没有必要让产品所有者参与进来。作为这里的技术专家，你有责任决定这种改变是否对你有长远的价值。如果现在花几天时间可以节省你数周的调试和错误修复，那就去做吧。没有必要向您的产品所有者解释这一点。

另一件事是把你正在做的事情称为重构。重构是短而快速的更改，可以立即提交到产品中，而不需要对最终用户进行任何可修改的更改。许多小重构可能会在很长一段时间内彻底改变软件的内部工作方式。你所做的听起来更像我所说的，是一次重新设计。但是，最终用户不应看到这一变化。

我相信您的更改可以分解为许多小的更改，随着时间的推移可以缓慢地部署。这将允许您检查是否有任何更改破坏了什么。它还为其他开发人员提供了更好地吸收变化和提供一些反馈的机会。

中距部署

这是什么？在sprint期间不应该进行部署。只有潜在的可部署工件才会在sprint的末尾创建。其他一切都应视为正在进行中的工作。如果您在sprint期间进行部署，那么我想知道为什么您甚至使用sprint，而不是连续的东西，比如看板。