compatibility - 向后兼容性与标准兼容性？

Question

假设您有一个需要维护的旧代码库，它显然不符合当前标准。在获得标准合规性的同时，您将如何分配您的努力以保持代码库向后兼容？对你来说什么是重要的？

Answer 1

在我的工作场所，我们没有时间仅仅因为它使代码更好而重构事物。必须有来自客户的错误或功能请求。

鉴于该规则，我执行以下操作：

当我重构时：

如果我必须对旧项目进行更改，我会清理、重构或重写我正在更改的部分。

因为我总是必须首先了解代码才能进行更改，所以这是进行其他更改的最佳时机。

这也是为您的更改和现有代码添加缺少的单元测试的好时机。

我总是先进行重构，然后再进行更改，这样我就更有信心我的更改没有破坏任何东西。

优先事项：

最需要重构的代码部分，往往包含最多的 bug。此外，对于客户不感兴趣的部件，我们不会收到任何错误报告或功能请求。因此，通过这种方法，优先级会自动出现。

规避不良设计：

我想有很多关于这方面的书，但这是对我帮助最大的：

我建造外墙：

1. 具有“隔离”现有不良代码的新良好设计的外墙。如果我必须编写新代码并且必须重用结构不良的现有代码，我会使用它，由于时间限制我无法更改。
2. 具有原始不良设计的外观，隐藏了新的良好代码。如果我必须编写现有代码使用的新代码，我会使用它。

这些外观的主要目的是区分好代码和坏代码，从而限制依赖关系和级联效应。

Answer 2

我会及时考虑修复模块，因为我需要使用它们。前期的重写/重构不会在任何合理的公司中进行，但是维护一个庞大的代码库而不对其进行一些清理几乎肯定是一场噩梦。