我不知道我是否可以在这里提出这样的问题，所以我先生道歉。
我使用的系统具有很多依赖关系和设计糟糕的数据库。现在我必须做出决定，并希望听到一些人的案例。
情况就是如此：软件的某些部分是在不考虑所有用途的情况下制作的。今天我需要做一些严峻的改变，比如在数据库上创建新的关系，重构所有的类和方法。这就是理论所说的，但是在实践中这需要很多天，会延迟版本和整个时间表。我可以选择保留gambiarra（有效的错误代码），并做出符合新需求的小改动。
我知道每个案例都不同，所以我想听听你会做什么，以及你是否经历过类似的事情。
答案 0 :(得分：1)
很难提供一些细节上的建议，但我认为你需要让利益相关者意识到他们所要求的是及时和昂贵的。
话虽如此，试着将所有这些工作分解为一系列可行的变化（我知道你已经有了一些用户故事）。逐步交付这些并优先排序，以便您的利益相关者尽快获得价值。
可能与他们一起举办研讨会，了解哪些对他们来说最重要，并将他们与实施的努力和风险进行权衡，这是让每个人在同一页面上保持一致的好方法。
祝你好运，听起来你需要它。答案 1 :(得分：1)
这是一种非常常见的情况。您没有提供任何具体细节，因此除了一般条款之外，很难回答。
在完成工作，担心未来和技术债务之间总是需要权衡。
担心未来 - 您认为在将来的版本中需要的功能 - 是一个很好的想法。 ＆＃34;我现在就把它放进去，然后它会使下一个版本更容易一些＃34; - 每一次，那是＆＃34;以防万一＆＃34;一点代码需要爱和关注，而且每一次，时机成熟时都不对。因此，我不建议为将来的用例构建支持。它减慢了你的速度，而你往往会猜测你以后需要什么。在敏捷中，他们使用YAGNI的首字母缩略词 - ＆＃34;你不会需要它＆＃34;。非常具体地回答您的问题 - 我不认为不支持未来用例的代码或设计是“坏”＆＃34;。
然而，你真的应该担心技术债务。您的代码是模块化的，由体面的测试用例覆盖，可读，不是太复杂？质量的一个方面是＃34;扩展它有多容易？＆＃34;。这是一个非常不同的问题 - 而且难以扩展的代码是错误的代码。
如果您发现自己处于这种情况，您可能希望向您的公司介绍technical debt的概念。有时，承担技术债务是一个很好的决定 - 而且我从未参与过一个没有某种程度的项目。但这是一个商业问题，而不是技术问题。它归结为＆＃34;您希望花费多少未来资金来维持或扩展此功能以换取更快地将其推出门？＆＃34;。如果这是最后一个版本，答案很可能是＃34;很多＆＃34;。如果这是长期发布计划中的第一个，那么答案可能就是＃34;不是很多＆＃34;。