在重构项目以提高可维护性时，有哪些目标？

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

祝你重构顺利！

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

• 即使你说没有单元测试，我还是要插入它们。在重构之前将复杂的逻辑封装在测试中。
• Jrud 对代码气味的回答很好。
• 另外，请继续学习the S.O.L.I.D. principals。

Answer 5

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

Answer 6

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