本书第四章为注重实效的偏执。
给出了提示30，你不可能写出完美的软件。
在“按合约设计”部分，给出了提示31，通过合约进行设计。如果语言不在代码中支持DBC，也可以把合约作为注释放在代码中。通过早崩溃，在问题现场找到和诊断问题要容易的多。
在“死程序不说谎”部分，给出了提示32，早崩溃。当你的代码发现，某件被认为不可能发生的事情已经发生时，你的程序就不再有存活能力，从此时开始，他所做的任何事情都会变得可疑，所以要尽快终止他，死程序带来的危害通常比有疾患的程序要小的多。
在“断言式编程”部分，给出了提示33，如果它不可能发生，用断言确保它不会发生。
在“何时使用异常”部分，关于异常的问题之一是知道何时使用他们。异常很少应作为程序的正常流程的一部分使用，异常应保留给意外事件。给出了提示34，将异常用于异常的问题。
在“怎样配平资源”部分，给出了提示35，要有始有终。他意味着，分配某项资源的例程或对象应该负责解除该资源的分配。对于需要不止一个资源的例程，可以对资源分配的基本模式进行扩展，给出了两个建议，1、已与资源分配次序相反的次序解除资源分配 2、在代码的不同地方分配同一组资源时，总是以相同的次序分配他们，这将降低发生死锁的可能性。
本书第五章为弯曲，或折断。
在“解耦与得墨忒耳法则”部分，提到把代码组织成最小组织单位（模块）、并限制他们之间的交互是适用于编码的好原则。为了使依赖关系保持最少，我们将使用得墨忒耳法则设计我们的方法和函数。给出了提示36，“使模块之间的耦合减至最少”。函数的得墨忒耳法则规定，某个对象的任何方法都应该只调用属于它自身，传入该方法的任何参数，他创建的任何对象，任何直接持有的组件对象的方法。遵循得墨忒耳法则将使代码的适应性更好，更健壮，但也会编写大量包装方法，这些包装方法会带来运行时代价和空间开销。所以，应平衡特定应用的正面因素和负面因素。
在“元程序设计”部分，给出了提示37，“要配置，不要集成”。要用元数据（关于数据的数据）描述应用的配置选项：调谐参数，用户偏好，安装目录等。我们的目标是以声明方式思考(规定要做什么，而不是怎么做），并创建高度灵活和可适应的程序。给出了提示38，“将抽象放进代码，细节放进元数据”。通过EJB这个可配置的动态系统的例子说明了元数据可怎样既用于配置应用，又用于降低代码编写的复杂度。
在“时间耦合”部分，提到我们需要容许并发，并考虑解除任何时间或次序上的依赖。给出了提示39，“分析工作流，以改善并发性”。给出了提示40，“用服务进行设计”。提示41，“总是为并发进行设计”。
在“它只是视图”部分，介绍了位于Model-View-Controller（MVC）惯用手法之后的关键概念：既让模型与表示模型的GUI分离，也让模型与管理试图的控件分离。给出了提示42，“使视图与模型分离”。
在“黑板”部分，给出了提示43，“用黑板协调工作流”。