当重构项目以提高可维护性时，有哪些目标需要关注？

Question

我有一个项目（大约80K行代码），在发布之前我有将近一个月的奢华重构和添加功能时间，只要我小心不要破坏任何东西。在这种情况下，我应该怎么做才能提高可维护性？请注意，这个项目没有单元测试，我也不打算添加单元测试，但如果这是普遍共识，我会考虑。

我应该寻找哪些关键问题并考虑修改或重构以提高软件的可维护性和质量？

编辑：对我来说需要进行单元测试已经很清楚了。这不是我曾经做过的事情，作为一个新手开发者，有哪些好的资源可以介绍给我学习单元测试（最好是使用VS2008的单元测试框架）？

- Firoso

---

没有单元测试，你怎么知道不会出现错误？ - Mez

很遗憾，目前来说，集成测试是我们最好的方法。 - Firoso

感谢大家迄今为止的反馈，我相信单元测试将是我要解决的第一个难题。有人可以推荐一些关于使用VS2008测试工具的资料吗？ - Firoso

大多数情况下，VS测试可以以非常标准的xunit测试风格进行。但是也有一些独特的功能。这是一篇有趣的阅读材料：http://msdn.microsoft.com/en-us/library/ms379625(VS.80).aspx - Reed Copsey

Answer 1

请注意，该项目没有进行单元测试，我并不打算在此添加单元测试，但如果这是共识，我会考虑。老实说，如果你的目标是提高可维护性，那么没有单元测试是无法替代的。这将是第一步。问题是，如果没有单元测试，就无法知道在重构过程中是否“破坏”了某些东西。单元测试为您的重构提供了一层安全保障。如果您没有验证重构不会改变行为的方法，特别是进行大规模重构，那么很难感到舒适。您可以进行一些小型重构-例如改善理解的小型重命名等，但任何大规模重构或任何旨在提高长期可维护性的设计风格重构都应在设计和编写帮助您保护自己的测试之后进行。

- Reed Copsey

---

虽然经常需要重构才能进行适当的单元测试。 - Jeff Sternal

对我来说，它们经常是相辅相成的。我会尽可能少地进行重构以获得良好的单元测试，然后重构已测试的部分，接着转移到下一个代码区域并重复这个过程。 - Reed Copsey

“testable” 的另一个词是 “decoupled”。为了独立地测试一个模块，你必须将其解耦。因此 TDD 强制你解耦模块。实际上，如果你遵循 TDD 的三个规则，你会发现自己比以前做更多的解耦。这迫使你创建更好、更少耦合的设计。” - user74754

Answer 2

关键要考虑的是为什么你想重构你的代码。回答这个问题，你就已经有了一半的答案。

你提到想要提高可维护性，这是重构的一个非常普遍的原因。鉴于这个目标，以下是我会具体关注的一些事情：

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

2）以简单为目标。每个函数/方法/类是否都清晰明确地定义了？你能否看着它知道它正在做什么？如果不行，那么它就是重构的一个好的目标。好的例子是做很多事情（或者有很多副作用）的模块。考虑将它们分成逻辑上分组的更小的模块。

3）变量/类/函数名称。它们是否清晰明确？它们不一定需要很长，但它们应该让你（或者维护代码的人）非常清楚变量是干什么的或者函数是做什么的。如果有一些不清楚的，考虑重新命名它们。

4）你有一些从来没有被调用的代码吗？如果你认为你以后会用到它，那么留下来可能是值得的。否则，它只会误导任何维护者。考虑将其删除。

5）性能增强。你可能没有时间进行完整的算法重写（最好的性能增强）。然而，这是检查简单事情的好时机。作为一个C++的例子，你是否将类作为const引用或按值传递？前者在可以使用时（这是95%的时间）更有效率。

祝你重构顺利！

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

- Russell Newquist

---

不想太苛刻，但性能增强并不等同于重构。（虽然前四个建议是不错的。） - Jeff Sternal

从技术上讲是正确的，但如果我在代码深处，这是我会寻找的东西。 - Russell Newquist

此外，我赞同下面所有人对单元测试的推荐。我本来想在我的初始答案中加上一条评论的。 - Russell Newquist

Answer 3

• 即使您没有要求单元测试，我仍然会提供。在重构之前，将复杂的逻辑封装到测试中。
• Jrud提到的代码异味很好。
• 此外，学习S.O.L.I.D.原则。

- Jeremy Roberts

Answer 4

我建议你查看本站关于代码异味的维基百科文章，那是一个很好的起点！

- Jrud

---

+1 - 通常与 http://wiki.java.net/bin/view/People/SmellsToRefactorings（从 Martin Fowler 的代码异味 bliki 条目 http://martinfowler.com/bliki/CodeSmell.html 链接）同等或更好。 - Jeff Sternal

Answer 5

拥有一个被充分测试覆盖的项目（包括单元测试，使用模拟等方式使其运行速度极快，以便您可以随时运行它们，以及集成测试，更少地运行实际与真实数据库接口等等）是可维护性的关键：这是您可以为任何目的（功能、错误修复、性能、移植等等）轻松维护项目的最重要的事情。强大的测试套件让您对任何进一步的具体更改的正确性充满信心，而且，重构为易于测试（高度模块化、依赖注入等等）的代码本质上也变得更加灵活和易于维护。

我强烈推荐Feathers的《与遗留代码有效工作》（我指向的PDF文件以及同名作者的书籍），这是一份全面而实用的指南，告诉您如何在这种情况下最好地进行。

- Alex Martelli

Answer 6

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

- Paul Graphov