建议：反模式反例
以前似乎没有人问过这个确切的问题，所以我会开火：
我们大多数人都熟悉反模式的概念。然而，避免实施反模式原则上可能会偏离太远并导致问题本身。举个例子，“委员会设计”有一个反例，我称之为“特立独行的设计”——其中一个重要功能的设计被交给个人去做他们认为最好的事情，目的是审查稍后他们的工作，并决定是否应该最终确定或进行另一次迭代。在实践中，这需要更长的时间，因为团队的其他成员都忙于其他事情，并且最终可能会得到一个对任何人都没有用的功能，特别是如果特立独行者本身不是经验丰富的最终用户。
有人还有更多反模式反例的例子吗？
It doesn't seem that this exact question has been asked before, so I'll fire away:
Most of us are familiar with the concept of an anti-pattern. However, avoiding implementation of anti-patterns can in principle swing too far the other way and cause problems itself. As an example, "Design by Committee" has a counter-example that I'd call "Design by Maverick" - wherein the design of an important feature is handed off to an individual to do what they think best, with the intention of reviewing their work later and deciding whether it should be finalised or go through another iteration. This takes much longer in practice as the rest of the team are occupied by other things, and can end up with a feature that's useful to nobody, particularly if the Maverick is not themselves an experienced end-user.
Does anyone have any more examples of anti-pattern counter-examples?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在反模式本身中看到了问题。指出错误的解决方案很容易，但提出好的解决方案却很难。解决方案的质量几乎总是取决于上下文，因此有时即使实施良好的反模式也可以比其他解决方案更多地使用。因此，解决方案或模式的空间一般来说是取之不尽用之不竭的，我们必须决定应该考虑哪些。错误的解决方案还是好的解决方案？我想看看不好的解决方案并知道它们是坏的并不像看看好的解决方案那么有用，因为从好的解决方案（常规模式）中，您还可以获得在提出该解决方案时使用的好的原则（就像GoF 设计模式书中的 OO 设计原则）。至于你的具体例子，我在某个地方听说过“仁慈的独裁者”和某种民主（有自己的名字），这是通过根据项目的不同优先级向某些人添加更多选票来进行调整的。
I see the problem in anti-patterns themselves. It is easy to point out wrong solutions, but it is harder to come up with good ones. Almost always the quality of solution depends on the context, so sometime even anti-pattern when implemented good can be used more than other solutions. So the space for solutions or patterns in general is quite inexhaustable and we have to decide which ones should be looked at. Wrong solutions or good soltions? I guess looking at bad solutions and knowing that they are bad is not as useful as looking at the good ones, because out of good ones (regular patterns) you can get also good principles which were used when comming up with that solution (as with OO design principles in GoF design patterns book). As to your exact example, I heard somewhere about "Benevolent Dictator" and some sort of democracy (with own name) which was adjusted by adding more votes to certain people depending on different priorities of the project.