使用预先存在的不良做法还是与旧代码不太适合的良好做法更好？

我之所以这样想，是因为我试图为现有的3rd party软件编写扩展，而他们的数据库却被严重地非规范化。我需要使用他们现有的表并添加一堆新字段。

我可以选择以其设计风格（包含几乎所有属性都放在一个大表中）创建新表，或者一起创建一组新表，并使用诸如触发器之类的其他功能在新表和新表之间同步数据。旧桌子。

我最终选择了使用现有不良设计风格的第一种选择，但是我面临的问题是：采用预先存在的不良做法还是实施与现有代码不能很好地配合的良好做法更好？在某些情况下，我应该选择一个？

注意：到目前为止，许多答案都与缓慢重构错误代码有关，但是我无法做到这一点。该代码不是我们的，供应商经常对其进行更新。我只能在上面建立。

在以下情况下，您应该选择更好的设计：

1. 您将接管未来编码的很大一部分

2. 从长远来看，更好的设计对客户而言并不昂贵。例如，我目睹了为期数月的“重构”，这些重构已于年底终止。

如果出现以下情况，则应选择“相同的不良样式”：

1. 你只是在帮忙。如果您只是一个兼职项目的补充，认为您可以邀请一个现有的小组并将他们提高到更高的设计标准是不现实的。更好的设计是主观的，几乎总是有学习曲线的。如果团队的其他成员没有学到新的设计，那么该项目将最终变成一堆杂乱的样式，而您设计更好的代码可能最终会变成一堆堆的东西，因为没人能理解，所以他们没有改变它。在上面的示例中，如果第三方软件有更新怎么办？

2. 牺牲“更好”的设计将为您带来切实的业务优势。就像严重添加功能X一样，您会获得大量合同，但是错过最后期限会使您一无所有。这就是mgmt与技术团队之间历史性冲突的所在。就像翻新房屋一样，有人必须决定何时付款。您可以通过一年没有电或自来水来生活来偿还债务。或者，您可以使用这些实用程序支付3倍的费用。

从长远来看，最好使用好的做法。由于更改将花费更少的时间来实施，因此将节省时间和精力。

如果可能的话，请采取一些少的步骤来重构良好的做法（例如：在SQL中，将将拒绝已修饰的表分解为规范化的表，并使用具有旧表名的视图）。

您会注意到，从长远来看，我说过-“质量，时间，金钱”三角形也适用于此（即-选择两个）。如果您没有时间，则可能必须遵循旧的做法，但这将意味着您正在增加问题，并且您的设计也需要修复。

如果您继续工作并添加不良设计的代码，那么您将永远不会获得使用良好设计的代码库。尽可能尝试使用良好的设计并重构为良好的设计。

好吧，我认为这在很大程度上取决于每种情况。如果性能和设计允许，最好使用良好实践。但是，例如，如果该表是高访问性表，那么创建触发器进行同步化可能会对性能产生负面影响。

现在，您的客户不会看到您使用了更好的设计，他只会看到您的解决方案使他的系统变慢了。此类决策应视具体情况而定，并且您应使用自己的经验和标准进行决策。

我认为您可能是正确的选择。

您应尽可能将应用程序代码与不良的数据设计隔离开。

您要更新他们的表格吗？如果不是，则创建SQL视图以方便您的应用程序的方式显示这些表。SQL视图相对容易编写，并且比应用程序代码更容易测试。

如果必须更新旧表，请考虑编写存储过程来管理更新。它们编写起来有点复杂，但是可以立即对其进行测试。

使用触发器规范化数据库时，使旧代码保持同步是一个很好的解决方案（如果它是临时的）。目标应该是更改旧代码，但是当与第三方打交道时，这可能行不通。您必须保持对模式更改的关注。

在错误的代码上堆积越来越多的功能会造成持续的问题。解决方法成为常态。用户将感到沮丧，因为更改将花费太长时间，并且可能会引入其他错误或限制。谁愿意当程序员说我们不能这样做而不是我们不应该这样做？

可以保留一些代码；我们并不总是那么奢侈。

您在这里处理技术债务。简而言之，技术债务意味着利息，您必须随着时间的流逝偿还利息，并且在某些时候，您必须偿还利息。

Develloper的时间花费金钱，因此技术债务可以像真实债务一样看待，并且花费真实金钱。

您基本上有两个主要解决方案，并且介于两者之间。您可以决定不想立即退还该债务，并继续支付利息。显然，从长远来看，这将花费更多，但现在您可以得到结果。您还可以选择退还该债务，因此只要您不退还就不再继续，但是最后，您没有任何利息。

通常，您有交货期限，错过期限会导致对客户的不信任，最终您会松懈。这可能是借贷技术债务的正当理由：您认为与客户一起获得的收益值得技术债务的额外支出。

您知道最后，您必须采用新的方法，否则，您将获得越来越多的债务，最终破产（您现在，当人们决定从头开始时或者项目严重失败时）。

您必须计划如何更改现有的代码库，并随着时间的推移过渡到新的实践，并每天逐一分发更改内容。在某些时候，当这些重构导致其他损失时，请考虑哪一种损失更为严重，并寻求最佳损失。

不重构的成本将随着时间的流逝而增加（这是技术债务的利益）。因此，这最终将成为最昂贵的选择。

确保老板了解技术债务的概念。即使采取预防措施，您也会造成技术债务。在某个时候，要用来退款的钱。故意创建技术债务时，您必须有合理的理由，并将债务视为投资（就像实际债务一样）。在任何其他情况下，请勿故意做技术债务。

您可能对演化数据库和部署这些演化的方法感兴趣：http ://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

顺便说一句，这是一项艰巨的任务，祝你好运。这值得 ！

这是一个典型的问题：“现在还是以后，我是否需要从工作中获得收益？” 而且我认为该答案永远不可能有通用的解决方案。只有您知道此决定涉及的所有因素（技术因素和人为因素）。

但是，您的问题提出了一个有趣的问题：

自动代码重构是否取得了足够的进展，以便应该更加重视代码统一性？

最终，不良的设计应该改变或消失。否则，这不是一个坏设计。这里真正的问题是关于重构的成本。从您的问题看来，您（或您的雇主）现在似乎不愿意付出代价，并且在当前的技术状态下，您不太可能愿意支付。

但是，代码重构自动化正在取得一些进步。如果编译器今天可以优化二进制文件，谁能说他们明天就不会优化代码？在某个时候，将推出某种工具，使开发人员和设计人员可以非常轻松地重构其代码，以适应新的需求。毕竟，处理遗留代码是当今最大的挑战之一。

如果有这样的工具存在（我不会对此感到惊讶），那么在做出这样的决定时最好考虑一下。

好的做法总是胜过穷的做法。如果您的代码库被错误的代码填充，则您不应该只是以同样的方式来培养自己的东西，而是应该正确编写代码，然后尝试以正确的方式来教育其他所有人。