可维护软件的四大支柱

引言

影响软件项目成功的最重要因素之一是软件的可维护性。而可维护性又常常受到软性因素的驱动——这些因素往往无法量化或轻易衡量。这也是为什么这么多项目产出质量低劣的软件并屡次错过截止日期的原因之一。管理者通常有涵盖工具、技术和流程的清单，但却错过了大局。与其采用严格的规则和清单，不如努力培养一种简单文化，直接促成高质量、可维护软件的创建。一家公司可以拥有优秀的工程师，但如果文化不正确，最终仍然会得到糟糕的产品。希望本文能阐明如何培养这种文化。

欠工程和过度工程的双重祸害

在我阐述如何做对之前，我想谈谈几个经常导致项目脱轨的问题。软件设计和开发常常沦为两个极端之一的牺牲品：过度工程或欠工程/黑客行为。

欠工程很容易解释，我们都见过。那些彼此不协调或只是养成了坏习惯的人，往往不会实践良好的设计策略。最终，代码开始变得像一团巨大的乱麻，本应只需几个小时就能修复的错误却要花费几天甚至几周。

同样常见，但可能不那么被认为是过度工程现象。这通常是那些学习了各种设计模式并认为应该在每一个环节（过度）使用它们的人所导致的结果。这种倾向也被称为“模式狂热”，实际上对项目的成功可能像系统架构不足一样危险。过度工程行为是有问题的，因为它会导致为实现每一位功能而包含有限的开销代码。随着时间的推移，这些开销会不断累积，并对产品的维护成本产生负面影响。

过度工程和欠工程系统的最终结果是一样的——即使是最简单的功能添加，软件的维护工作也变得繁重。这种维护开销导致了日程的定期延误和开发人员的沮丧。

四大支柱

记住我所说的可维护软件的四大支柱，将有助于确保您的产品不会变成一个难以驾驭的庞然大物。

请注意，这些原则乍一看可能显得有些显而易见，但它们却很容易被忽视或轻视。你会惊讶于有多少人声称他们的开发技术遵循这些原则，但他们的工作却完全无视这些原则。你会注意到我没有涵盖我们都听说过的一些具体建议，比如代码注释。在这一点上，绝大多数开发人员都知道他们应该注释代码，然而许多人却忽略了成功软件开发中更模糊的方面，在我看来，这些方面甚至更为重要。

支柱一：KISS – 保持简单，傻瓜式

你可能听说过KISS原则——Keep It Simple Stupid（保持简单，傻瓜式）。正如其所暗示的，这意味着你应该始终在产品的各个方面保持简洁——从设计到实现，甚至软件流程。大型项目固有的复杂性已经让开发和维护足够困难，如果再由不同的人引入不必要的开销，只会雪上加霜。

KISS 是一种心态，应该灌输给项目中的每一个人。许多人甚至大多数人对复杂性没有真正的认识，并且常常严重低估少量复杂性随着时间的推移可能对产品造成的负面影响。

KISS 可应用的几个示例问题

• 我们为什么要实现这种设计模式？有没有更简单、更高效、更容易维护的模式？
• 有没有更简单的方法来实现这段代码？
• 我们流程的每个部分都合理吗，或者有没有办法让它更高效？
• 代码或流程中是否有我们倾向于重复的、可以简化的部分？

支柱二：YAGNI – 你不会需要它

来自极限编程（链接）世界的是YAGNI，或者说“你不会需要它”的规则。顾名思义，在设计和编码时，要真正思考你正在添加的功能是否真的会被添加，还是你只是“以防万一”地添加它。大多数情况下，这些“以防万一”的添加最终从未被使用，只是增加了产品的维护开销。

如果你让代码尽可能简单，并且你最终在以后需要一些功能，通常插入新功能不是什么大问题，因为代码非常简单，并且你有很好的测试覆盖率，这让你有信心以后不会破坏任何东西。

XP/测试驱动设计社区的态度比我更强硬——他们声称即使你知道在不久的将来会需要某项功能，但此刻并非迫切，也不要添加它。我倾向于认为，如果我确切知道某项功能是必需的，并且我已经在这部分代码中或正在设计系统的该部分，那么就直接添加它。

YAGNI示例问题

• 我正在实现的功能现在绝对需要吗？
• 我正在实现的功能在未来极有可能被需要，还是我正在做一种“以防万一”的事情，而这种事情很有可能永远不会被使用？

支柱三：DRY - 不要重复自己

DRY是一个实际上驱动了许多设计模式和重构建议的原则。最大的维护问题之一是当你的代码在整个项目中重复出现时。在这种情况下，通常会发生的是，当这些代码副本中的一个需要更新时，开发人员需要搜索整个代码库并更新所有副本。迟早会有一个或多个副本未能得到更新，从而引入错误。此外，逻辑的副本增加了需要维护的代码总量，这使得产品总体上更加混乱。

因此，简而言之，当你看到一段你正在复制/粘贴的代码时，将其提取到它自己的方法或模块中。这样在未来出现错误的几率会大大降低，并且更容易维护。

支柱四：保持条理

在项目的每个部分都要保持条理；从公司服务器上文档的存放位置，到代码文件的布局方式，到类的命名方式，到产品的安装方式，甚至在谈论和撰写各种概念时，都要确保以一致的方式引用它们。

我发现适当的组织在软件项目中常常被低估，这是一种遗憾，因为糟糕的组织会降低可维护性以及项目长期成功的机会。当事情没有组织时，意味着团队成员需要死记硬背随机的信息。这种记忆开销会分散清晰思考问题的心智，并混淆团队成员之间的沟通。因此，糟糕的组织可能导致“愚蠢”错误的引入，甚至间接导致项目进度延迟。

确保项目的各个部分都井然有序，也可以缩短新员工的适应期。这是因为当一个项目组织得当，公司就不会那么依赖现有成员的“部落知识”。新成员只需遵循一致的模式，就能更容易地了解事物是如何运作以及信息在哪里。

一切都关乎心态

这些支柱可能看起来显而易见甚至有些平淡无奇，但它们的目的是强化一种简单的心态，这种心态直接导致创建可维护、高质量的软件。除了聘请有才华的个人，公司还必须确保文化能强化良好的软件开发。文化不能仅仅是催促截止日期，对代码质量口头敷衍，并声称只要我们实施模式X、Y和Z就一切都会好。项目所鼓励的心态对于可维护软件的生产至关重要。

历史

• 2009年6月30日：首次发布