设计模式和反模式

您的系统或代码中是否有一部分似乎总是坏掉，或者它太复杂以至于没有人愿意为它工作，因为它总是坏掉?如果是这样，那么您可能有使用反模式的坏习惯。反模式是好的设计模式的邪恶双胞胎。好的设计模式是一种可重用的需求、设计或实现，它以一种标准的方式解决困难的问题，这种方式设计良好、文档记录良好、易于维护，并且易于扩展。反模式是一种设计模式，它在某些时候似乎是合理的，但已经扩散到系统或代码的许多不同部分，现在是维护或扩展的噩梦。

20%的代码，80%的问题

反模式通常是导致系统80%问题的20%的根本原因。

反模式可以出现在需求、设计或代码中。在需求中，它们是在需求规范的不同部分中编写的不一致或冲突的需求。每个需求本身似乎都是合理的，但是当它们组合在一起时，它们会导致试图解决冲突的过于复杂的系统。

在设计中，反模式通常产生于复制以前系统中需要的模式，例如在PLC中处理字符串或在PC中复制文件，但这不再需要，并且增加了复杂性并降低了性能。典型的反模式涉及异常处理。现代语言包含“catch”和“try”方法来简化异常处理，但从旧系统复制的模式将具有深度嵌套的条件，几乎不可能调试或更改。除了错误处理之外，反模式还可能与安全设置、复杂的数据操作和字符串数据操作有关。通过糟糕的编程技术，反模式会出现在代码中。这些反模式可以像使用单个字符作为变量名一样简单，因为“这是我们在Fortran中使用的方式”;超长的模块和函数，因为“这是我们在Basic中必须做到的方式”;或者是一次一个字节的接口，因为“旧的网络只支持一次一个字节的传输”。

熟悉，无需回顾

反模式实际上只是一种坏习惯，在这种习惯中，来自以前项目的模式被重用而不进行审查。他们没有被审查，因为每个人都说，“我们一直都是这么做的，所以我们不需要看那部分。”

反模式可能并不总是糟糕的编程或设计技术的标志;它们通常是一个坏算法的选择。在对一个项目中包含超过100万行代码和数百个模块的系统的分析中，我们发现一小部分模块导致了大多数问题，甚至对模块的大小进行了校正。我们通过几种方式衡量大小:代码行数、语句数和每个语句的变量数。在所有情况下，相同的模块都出现在正常范围之外。它与开发人员或系统的任何特定部分没有关系。经过分析，我们发现所有的问题都与糟糕的算法选择有关。一个糟糕的算法，即使是由一个优秀的程序员编写的，仍然会引起更多应该预料到的问题。如果反模式有一个不好的原因，那就是缺乏对算法的审查，以及在多个地方只使用相同模式的传统。

识别系统中的反模式很容易。要求维护者识别代码中的反模式，即导致80%问题的20%的代码。要求编码人员识别设计中的反模式，即20%的设计占用了80%的代码。要求设计人员识别需求中的反模式，即20%的需求构成了80%的设计复杂性。反模式通常对创建它们的团队不可见，但对系统生命周期中的下一个团队可见;你只要问他们就行了。

分配以修复旧代码

修复反模式可能很困难。通常，在发现反模式后修复反模式的成本必须与任何持续维护费用或重新设计费用进行权衡。如果您希望多次扩展或修复反模式部分，那么重新设计和重新实现通常更具成本效益。不幸的是，这是一个很难证明的决定，因为付款可能会很慢。幸运的是，删除反模式并不一定要一次性完成。一个合理的经验法则是将维护预算的10%-20%用于用良好的设计模式替换反模式。随着时间的推移，您将发现随着坏模式被好模式取代，维护和支持成本将趋于稳定或下降。

消除反模式将使您的系统更容易维护和扩展，但一定要在项目、需求、设计和代码的所有部分中寻找反模式。不要让不审查的坏习惯给您的系统将来埋下反模式问题的种子。

- Dennis Brandl是北卡罗来纳州Cary BR&L咨询公司的总裁，www.brlconsulting.com。他的公司专注于IT制造业。请通过dbrandl@brlconsulting.com联系他。由CFE Media内容经理马克·t·霍斯克编辑，控制工程．

www.globalelove.com/it

您是否具有本内容中提到的主题的经验和专业知识?你应该考虑为我们的CFE媒体编辑团队做出贡献，并获得你和你的公司应得的认可。点击在这里开始这个过程。