以前似乎没有问过这个确切的问题，所以我会开火：
我们大多数人都熟悉反模式的概念。然而，避免反模式的实现原则上可以在另一方面摆得太远并且本身会引起问题。例如，“委员会设计”有一个反例，我称之为“Maverick设计” - 其中一个重要特征的设计传递给个人做他们认为最好的事情，目的是审查他们以后的工作，决定是否应该最终确定或进行另一次迭代。这在实践中需要更长的时间，因为团队的其他成员都被其他东西占用，并且最终可能会有一个对任何人都没用的功能，特别是如果Maverick本身不是一个经验丰富的最终用户。
有没有人有反模式反例的例子？
答案 0 :(得分：0)
我在反模式中看到了问题。很容易指出错误的解决方案，但很难找到好的解决方案。解决方案的质量几乎总是取决于上下文，因此有时甚至反模式实现良好时可以比其他解决方案更多地使用。因此，解决方案或模式的空间通常是非常不可能的，我们必须决定应该查看哪些。错误的解决方案或良好的解决方案？我想看看糟糕的解决方案并且知道它们是坏的并不像看好的解决方案那样有用，因为出于好的解决方案（常规模式），你也可以获得在使用该解决方案时使用的良好原则（如同在GoF设计模式书中的OO设计原则）。至于你的确切例子，我听说某个地方有“仁慈的独裁者”和某种民主（有自己的名字），根据项目的不同优先顺序，通过向某些人增加投票来调整。