refactoring - 在重构项目以提高可维护性时，要针对哪些内容？

Question

我有一个正在处理的项目（大约 80K LOC），只要我小心不要破坏任何东西，我就有将近一个月的豪华重构和功能添加时间。话虽如此，我能做些什么来提高可维护性。请注意，该项目没有进行单元测试，我并没有真正计划为此添加单元测试，但是如果这是普遍共识，我会考虑它。

我应该寻找并考虑修改或重构以提高软件可维护性和质量的关键事项是什么？

编辑：我很清楚我需要单元测试。这不是我真正做过的事情，对于刚接触单元测试的开发人员（最好通过 VS2008 的单元测试框架）有什么好的资源？

Answer 1

请注意，该项目没有进行单元测试，我并没有真正计划为此添加单元测试，但是如果这是普遍共识，我会考虑它。

坦率地说，如果您的目标是提高可维护性，那么单元测试是无可替代的。

这将是第一步。问题是，如果没有单元测试，就无法知道你在重构过程中是否“破坏”了某些东西。

单元测试为您的重构提供了一层安全保障。如果您无法验证您的重构不会改变行为，那么很难对重构感到舒服，尤其是在进行大规模重构时。

您可以进行一些小的重构 - 小的重命名以提高理解等，但是任何大规模的重构，或任何设计风格的重构以提高长期可维护性都应该在设计和编写帮助您保护自己的测试之后进行。

Answer 2

要考虑的关键是为什么要重构代码。回答这个问题，你就会得到一半的答案。

您提到想要提高可维护性，这是重构的一个非常常见的原因。鉴于这是一个目标，以下是我要特别针对的一些事情：

1）删除重复代码。无论如何，大多数程序员都试图避免这种情况，但是大型项目（尤其是大型团队的项目）往往会累积它。这是一个容易重构的目标。

2）让简单成为你的目标。每个功能/方法/类是否明确定义？你能看到它并清楚地知道它在做什么吗？如果不是，它是重构的好目标。很好的例子是做很多事情（或有很多副作用）的模块。考虑将它们分解为具有逻辑分组功能的较小模块。

3) 变量/类/函数名称。他们清楚吗？它们不一定需要很长，但它们应该让您（或维护代码的任何人）非常清楚变量的用途或函数的作用。如果有一些不清楚，请考虑重命名它们。

4) 你有永远不会被调用的代码吗？如果您认为以后会使用它，则值得离开。否则，对于任何维护者来说，这只是一个红鲱鱼。值得考虑摆脱它。

5) 性能增强。您可能有时间也可能没有时间进行全面的算法重写（最佳性能增强）。但是，这是检查简单事物的好时机。作为 C++ 示例，您是将类作为 const 引用还是按值传递？当您可以摆脱它时（这是 95% 的时间），前者的效率要高得多。

祝你重构好运！

[编辑] 另外，我建议下面的每个人在重构之前编写单元测试以确保您的代码保持正确。

Answer 3

• 即使您说没有单元测试，我还是要插入它们。在重构之前将复杂的逻辑封装在测试中。
• Jrud 对代码气味的回答很好。
• 另外，学习SOLID 原则。

Answer 4

有一个项目很好地覆盖了可靠的测试（两个单元测试，使用模拟和c运行得非常快，所以你可以一直运行它们，并且集成测试运行得更少，实际上与真实数据库接口等等）是可维护性的关键：您可以做的最重要的事情是使项目易于维护以用于任何目的（功能、错误删除、性能、移植等）。强大的测试套件让您对未来可能想要尝试的任何进一步特定更改的正确性充满信心，此外，代码重构为可良好测试（高度模块化、依赖注入等）本质上也变得更加灵活和可维护。

我强烈推荐 Feathers 的Working Effectively With Legacy Code（我指向的 PDF 和同名同作者的书），以获得如何在这种情况下最好地进行的全面且高度实用的指南。

Answer 5

我会在这个网站上查看关于Code Smells的 wiki 文章，这是一个很好的起点！

Answer 6

寻找未来可能发生变化的地方，并使其更加灵活。