Gnaixuy

通常来说，致力于改善团队开发效率的同事会陷入两难的局面，要么他们会和他们所服务的开发者产生冲突，要么他们的时间都花费在一些截止时间遥遥无期的项目上面，因为大家对这些项目漠不关心。

有时候人们在调试代码时会感受到强烈的挫败感。因为绝大部分人在调试系统代码时，倾向于将时间花费在思索而不是追溯代码的调用上。

当你在解决代码中的问题时，你不应该止步于只修复问题表象。而是应该确保问题彻底消失并且永远不会再发生。开发者通常在修复完问题症状之后就认为完事大吉了。确实从某种意义上说你已经修复了bug，也没有人再抱怨

bug来自哪里？我们能把所有bug的成因范围缩小至一个或者几个之内吗？答案是肯定的。 bug通常来自开发者尝试降低代码复杂性未果而产生的副作用。也有部分来自对其实简单的代码产生的误解。

当谈论bug时我们究竟谈论的是什么? 这里是关于bug的精确定义： 1.程序的行为并没有符合程序员的预期。 2.程序员的预期没有满足绝大部分理性用户的期望。 通常来说只要程序能够严格执行程序员给出的指

这个类比的独到优势在于，它囊括了你所需要了解的关于软件设计的一切知识原理。 无论你的团队只有你一个人还是有上千人，无论你的项目只有十行代码还是一千万行代码，上面的流程和准则都适用于你正在进行的软件开发

该原则中**至关重要**的一点是立即采取行动。我不允许代码中存在两种相互竞争的实现。我当下就将它们合并成了一个通用解决方案。另一个**重点**是我不会把它抽象得过于通用——抽象之后的解决方案只支持WA

我坚持认为计算机永远不应该“猜测”或者说“尽全力满足”用户的输入。由此引入的噩梦般的复杂性会导致程序极易失控。输入要么是对要么是错，不存在“也许”这种情况。如果一个输入有可能包含多层含义，要么你应该为

未来难以预测，但是对未来做出适当的判断非常重要。 有一个理论的基础版本是： 预测“Hello World”程序在遥远的未来的行为非常简单。当你在未来某个时刻运行它时，大概率会继续打印出“Hello W