不良系统设计上的代码重构

获取并阅读有效使用旧代码。它完全处理这种情况。

正如其他人也建议的那样，为了重构，你需要一套可靠的单元测试。但是，遗留代码通常很难按原样进行单元测试，因为它尚未编写为可进行单元测试。所以你需要首先重构以允许单元测试，这将允许你开始重构...一个糟糕的捕获。

这就是本书将帮助你的地方。它提供了许多实用的建议，说明如何使设计不良的代码单元可测试，并尽可能少地进行最安全的代码更改。自动重构也可以在这里帮助你，但是书中描述了一些技巧，这些技巧只能手动完成。然后，一旦第一组单元测试就位，您就可以开始逐步重构，以开发更好、更易于维护的代码。

更新：有关如何接管遗留代码的提示，您可能会发现我之前的这个答案很有用。

正如@Alex所指出的，单元测试对于理解和记录代码的实际行为也非常有用。当有关系统的文档不存在或过时时，这尤其有用。

首先关注稳定性。在围绕应用程序建立某种稳定的环境之前，您无法增强或重构。

一些想法：

1. 版本控制。你已经通过设置颠覆开始了。现在，请确保您的数据库架构、存储过程、脚本、第三方组件等也处于修订控制之下。拥有版本标签系统，确保您标记版本，并且可以在将来准确访问旧版本。
2. 构建和发布。有一种方法可以在开发计算机以外的计算机上构建稳定版本。您可能希望使用 ant/nant、make、msbuild，甚至是批处理文件或 shell 脚本。如果部署脚本/安装程序不存在，您可能也需要它们。
3. 对其进行测试。在有办法知道您的更改是否破坏了它之前，请不要更改该应用程序。为此，您需要进行测试。您应该希望能够为一些更简单的独立类编写 xunit 单元测试，但请尝试构建一些系统/集成测试来执行整个应用程序。如果没有高代码覆盖率（您不必从一开始就这样做），集成测试是您最好的选择。养成尽可能频繁地运行测试的习惯。抓住每一个机会来扩展它们。
4. 进行小的、集中的更改。尝试识别应用程序中的系统/子系统，并改善它们之间的边界。这可以减少您可能所做的更改的连锁反应。当心通过重新格式化代码或强加最新的时尚设计模式来“美化”代码的诱惑。扭转这样的系统需要时间。
5. 文档。这是必要的，但不要太担心。根据我的经验，系统文档很少使用。好的测试通常比好的文档更好。专注于记录应用程序与其运行的系统上下文（输入、输出、文件结构、数据库模式等）之间的接口。
6. 管理期望。如果它的状态不好，那么它可能会抵制你做出改变的努力，并且时间尺度可能比平时更难估计。确保管理层和利益相关者理解这一点。

不惜一切代价，当心重写整个事情的诱惑。在这种情况下，它几乎从来都不是正确的做法。如果它有效，请集中精力保持其工作。

作为初级开发人员，不要害怕寻求帮助。正如其他人所说，《有效使用遗留代码》是一本值得一读的好书，Martin Fowler的《重构》也是如此。

祝你好运！