是否曾经证明使用公认的反模式在某个特定情况下确实有效?你有没有通过使用反模式在你的一个项目中解决问题或获得任何好处?
6 回答
我对“反模式”概念的理解是,它包含的解决方案具有只能在长期内显现出来的缺点。事实上,与其中许多相关的主要危险——比如编写带有大量全局变量和 goto 的意大利面条代码,或者将异常扔进一个空块的黑洞catch
——是它们很诱人,因为它们为眼前的问题提供了一种权宜之计。
编辑补充:因此,有时您确实从这些反模式中受益。有时你认为你正在编写没有人会再次接触的一次性代码的计算是完全错误的,你最终会遇到维护程序员诽谤你的传统和性卫生,但其他时候你是对的,那个糟糕的 shell 脚本与打包在一起wire and spit 完成了您打算做的工作,然后幸运地被遗忘了,从而为您节省了大量时间和精力来整理一些像样的东西。
反模式仍然如此广泛,仅仅因为它们解决了一个特定的问题(同时创造了 10 个新问题)。也称为解决方法。但是他们怎么说呢?没有什么比临时搭建的更持久。
事实上,如果事情从一开始就做好,我相信我们都会失业。
根据我的经验,它解决的最大问题是启动一个新应用程序。
当开发团队彻底确定了新应用程序的范围时,实施正确解决方案的时间线通常对管理层来说太长了。因此,通常情况下,您编写代码是为了满足时间表,而不是解决方案的“正确性”以达到发布日期,(但让其他人为下一个版本编写“正确”解决方案),使其本质上是“丢弃”代码。
一种软件反模式是Softcoding,也在每日 WTF中定义。当程序员将“应该”在代码中的材料放入外部资源时,就会发生软编码。
我正在使用某些人可能会说受到软编码影响的软件。外部文件驱动软件。这些外部文件是一种微语言:必须先将它们编译为 XML,然后软件才能使用它们。这种微语言有它自己的工具。
但是软编码总是在旁观者的脑海中。
拥有自己的解析器的微语言材料让我的生活更轻松。一个数据源可以生成许多不同的输出:除了主程序使用的版本之外,我还能够将信息提取为 HTML、.csv 和客户想要的其他格式。其他程序可以用微语言生成代码,使自动化更容易。
在我们的例子中,软编码是一种有用的模式,而不是反模式。
将其称为模式而不是法律是有原因的。
我推测几乎每个人都至少有一个例子说明代码中有一个地方确实做了错误的事情,而且从长远来看,它比“正确”的事情做得更好。
还有更长的反模式导致麻烦的示例列表。
出于无知或懒惰,我已经多次使用魔法按钮,有时它实际上工作得很好,结果证明我不需要适当的 MVC 的额外抽象。