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

Question

我是一个初级的软件工程师，他被赋予了接管一个旧系统的任务。根据我的初步评估，这个系统有几个问题。

1. 意大利面码
2. 重复码
3. 具有10k及以上行的类
4. 使用log4j的误用和过度记录
5. 糟糕的数据库表设计
6. 缺少源代码管理->为此设置了Subversion
7. 缺少文档->我不知道业务规则，只是阅读代码

我应该怎样做才能提高制度的质素和解决这些问题呢？我可以考虑使用静态代码分析软件来解决任何错误的编码实践。

然而，它不能检测到任何坏的设计问题或问题。我应该如何逐步解决这些问题？

Answer 1

首先要注重稳定。在应用程序周围有某种稳定的环境之前，您无法增强或重构。

一些想法：

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

不惜一切代价，谨防仅仅重写整件事的诱惑。在这种情况下做这件事几乎是不对的。如果成功了，就集中精力让它继续工作。

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

祝好运!

Answer 2

获取并阅读有效地使用遗产代码。它正好处理这种情况。

正如其他人所建议的那样，对于重构，您需要一组可靠的单元测试。然而，遗留代码通常很难像现在这样进行单元测试，因为它还没有被编写成可测试的单元。因此，您需要首先重构以允许单元测试，这将允许您开始重构.一个糟糕的圈套。

这就是这本书能帮助你的地方。它给出了很多实用的建议，说明如何使设计糟糕的代码单元在尽可能少的、最安全的情况下测试代码。在这里，自动重构也可以帮助您，但是书中描述的一些技巧只能手工完成。然后，一旦第一组单元测试就绪，您就可以开始逐步重构，以获得更好、更易于维护的代码。

更新:关于如何接管遗留代码的提示，您可能会发现这个我早些时候的回答很有用。

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

Answer 3

首先，不要修复那些没有被破坏的东西。只要您要接管的系统工作，就不要再使用功能了。

然而，当涉及到可维护性时，系统显然是坏的，所以这就是您要解决的问题。如前所述，首先编写一些测试，在cvs中备份源代码，然后首先清理小块，然后清理较大的部分等等。不要攻击更大的架构问题，除非您对系统的工作方式有了很好的了解。工具不会帮助您，只要您自己不深入代码，但当您这样做，他们确实有很大帮助。

记住，没有什么是“完美”的。别太过工程师了。遵守接吻和雅格尼原则。

EDIT:添加了YAGNI文章的直接链接