有时，某人有解决问题的好主意。但随着时间的推移，人们忘记了为什么它是一个好主意，并试图以最终导致与该想法最初应该解决的问题一样糟糕(或更糟)的问题的方式使用它。
例子:
I'm sure that distributed source control is sufficiently counterintuitive that people try to establish conventions that defeat the point of distributed source control.
示例 2:
it's very natural to think that when you're writing some code, you should handle all errors that could possibly arrise. But a function doesn't always have enough information to handle the error properly, so all it can do is somehow tell whoever called it that the error occured. Passing errors up the call stack by hand is tedious, so exceptions were invented. With no extra typing on the part of the programmer, exceptions will bubble up the call stack until somebody can do something with them. It seems like checked exceptions, at least in practice, tarnish the awesomeness of exceptions. At best, the programmer has to tediously work her way up any possible call stack, specifying that every method throws a given exception up to the point where it can be handled (if it can be handled). Worse, she might swallow the exception to avoid the chore!
还有哪些其他示例表明，看似常识性做法的方法实际上是重现已以某种方式解决的问题？
这个问题的要点:将常识性“显而易见”的解决方案的错误内化是一种非常好的方式，可以培养一种直觉，了解如何以及为什么使用最初违反直觉的优雅解决方案。
最佳答案
嗯……让我想想……Web 工作的基础是什么——无状态 HTTP，许多有状态框架(ASP.NET、JSF 等)都建立在无状态 HTTP 上，完全抛弃了无状态的性质协议(protocol)？好吧，不是在他们的实现中丢弃它，而是为他们的用户丢弃它 - 甚至对基本 Web 元素一无所知的开发人员试图将数兆字节的序列化对象打包到页面中，这会导致性能损失以及流量和服务器资源的巨大消耗。
它会落入你的概念定义吗？
关于language-agnostic - 被误解的好主意，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1290350/