有时某人有一个很好的主意可以解决问题。但随着时间的推移，人们会忘记为什么这是一个好主意，并试图以最终造成问题的方式使用它，而不是最初想要解决的问题。
示例：
我确定分布式源代码 控制是充分的 人们试图违反直觉 建立打败的公约 分布式源代码控制点。
示例2：
认为什么时候很自然 你应该写一些代码 处理可能发生的所有错误 arrise。但功能并不总是如此 有足够的信息来处理 错误，所以它能做的就是 不知何故告诉谁谁叫它 发生错误。传递错误 手动调用堆栈是乏味的，所以 发明了异常。没有 额外打字的部分 程序员，例外会冒泡 调用堆栈，直到有人可以做 与他们的东西。这好像是 检查异常，至少在 练习，玷污了真棒 例外。充其量是程序员 任何人都必须繁琐地工作 可能的调用堆栈，指定 每个方法抛出一个给定的异常 直到可能的程度 处理（如果可以处理）。更差， 她可能会把这个例外吞下去 避免做家务！
其他一些例子中，一种看起来像常识性事物的方法实际上是在重建一个以某种方式解决过的问题？
这个问题的要点：将常识“明显”解决方案的内部错误内化是一种非常好的方式，可以为如何以及为何使用最初违反直觉的优雅解决方案提供直觉。
答案 0 :(得分：2)
嗯.....让我想一想......网络运作的基础是什么 - 无状态HTTP，其上构建了许多有状态框架（ASP.NET，JSF等），完全抛弃了无状态的性质协议？好吧，不要在实现中丢弃它，而是为其用户丢弃它 - 开发人员甚至不了解基本Web元素，尝试将兆字节的序列化对象打包到页面中，这会导致性能损失和流量和服务器资源的大量消耗。 / p>
它会落入你的概念定义吗？
答案 1 :(得分：0)
你是对的，DVCS有很多例子。最常见的一种方法是使用像Subversion这样的DVCS，总是推动任何提交或过去的日子，甚至不必费心去提交。