你在为你的产品代码编写自动化测试。恭喜你！你还在写代码之前就写了测试？那就更棒了！！仅仅是这么做就可以让你成为一名软件工程实践的先行者。但你写的测试是优秀的吗？如果有一种提问：“我为谁而写测试？”你会怎么回答？若是回答：“为了我，在修复bug上的努力”或者“为了编译器，让它们能够跑起来”，那么你写的测试未必是最好的。所以你到底是为谁而写测试？为了那些想要了解你代码的人们。
用示例编写小函数
Write Small Functions Using Examples
我们都想编写正确的函数，并证明它是正确的。这可以让我们带着问题思考一个函数的“大小”。这不是指函数实现的代码量（尽管那也很有趣）而是指我们代码所体现的数学函数的大小。
例如，在围棋游戏中有一个称为Atari的条件，玩家的棋子可能会被对手捕获：一颗棋子周围有两个及以上的空格即自由，否则即Atari。计算一颗棋子的自由度很困难，但推断它是否为Atari就很简单。我们可以写出类似这样的函数：
编写代码，余生都要支持它
Write Code as If You Had to Support It for the Rest of Your Life
你可能会问97个人程序员应该知道什么并且如何做，可能你会得到97种不同答案。这可能会同时令人迷茫和生畏。所有的建议都是好的，所有的原则都是正确的，所有的故事都很引人注目，那么你要从哪里开始？更重要的是，一旦你开始，你又如何保持最佳的学习实践，如何确保它们能被集成进你的编程实践中呢？
当程序员和测试员合作后
When Programmers and Testers Collaborate
当测试员和程序员开始合作后会有一些奇妙的事情发生。通过缺陷追踪系统来回发送bug所花费的时间更少。浪费在争论这是一个bug还是一个feature的时间会更少，而更多的时间则用于开发出消费者可期的良好软件。在开始写代码之前的合作将会产生很多机遇。
WET稀释了性能瓶颈
WET Dilutes Performance Bottlenecks
DRY原则（Don’t Repeat Yourself）的重要性是它整理了这样一个概念：系统中的每个知识片段都应该有单一的表现形式。换而言之，每个知识点应该被包含在单独的实现中。DRY的对立面是WET（Write Every Time）。当知识点被整理在几个不同的实现中，我们的代码就是WET的。当你考虑DRY和WET的性能曲线的多种影响时，它们之间的对比就会非常明显。
繁琐的日志会打扰你睡觉
Verbose Logging Will Disturb Your Sleep
当我遇到一个已经开发并在生产环境跑了一段时间的系统时，我最怕的就是那个脏日志。你知道我在说什么：当点击web页面上那个单连接，系统就会反馈犹如潮水般的日志消息出来。可过多的日志根本没什么用。
采用正确的算法和数据结构
Use the Right Algorithm and Data Structure
一家用于众多分行的大型银行他们给出纳新采购的电脑实在太慢了。那个时候还没有电子银行，也不想现在到处都是ATM机。人们会经常去银行办理业务，由于电脑慢导致人们排起长队。因此，这家银行向供应商威胁要终止合同。
Unix工具是你的朋友
The Unix Tools Are Your Friends
如果我被放逐沙漠，不得不在IDE和Unix工具箱之间做出选择，我会毫不犹豫选择Unix工具。这就是你应该熟练掌握Unix工具的原因。
首先，IDE用于特定语言，但Unix工具可运行于任何以文本形式出现的事物。现如今的开发环境，每年都会涌现出新的语言和符号，学习在Unix环境下工作将是一种复利投资。
为你的朋友“乌班图”编程
Ubuntu Coding for Your Friends
很常见，我们独立写的代码，这些代码就会折射出我们个人对问题的理解，以及非常个人的解决方案。我们可能是团队的一份子，但我们在团队中也是独立的。这就让我们很容易忘记这些独立编写的代码会被其他人执行、应用、扩展以及依赖。这很容易忽略掉软件创造的社交方面。创建软件是一项技术活动，它与社会活动混合在一起。我们只需要经常抬头去想，我们并不是在独立的工作，我们有责任为每个人而不是开发团队，增加成功的可能性。
两个错误导致一个正确（而且难以修复）
Two Wrongs Can Make a Right (and Are Difficult to Fix)
代码时不会说谎的，但它会自相矛盾。有些矛盾还会导致“这怎么可能跑得起来？”的时刻。
在一次采访中，阿波罗11号月球模块的首席设计师，Allan Klumpp透露，控制引擎的软件有个会导致着陆舱不稳定的bug。然而，另一个bug却弥补了它，在这些bug被发现并修复之前，软件都被应用于阿波罗11和12号登月。