多道程序设计是设计中的荒蛮之地，几乎没有好的实践方针。许多程序员尽管精于判断如何将代码分解成子过程，然而最终还是编写出单个庞然大物般的单进程程序，而这些程序往往失败在自身的内部复杂度之上。

Unix 设计风格都运用“做单件事并做好” 的方法，强调用定义良好的进程间通信或共享文件来联通小型进程。

尽管将程序划分成协作进程带来了全局复杂度降低的好处，但代价是我们必须更多地关注在进程间传递信息和命令的协议设计(在所有种类的软件系统中，接口都是 bug聚集之地)。
- 协议必须 看得出 很有表现力，即人们必须能够在头脑中尝试对通信程序的行为建模并验证其正确性。

#7.1 从性能调整中分离复杂度控制

在开发出可以把全局复杂度降至最低程度的干净体系之前，关注性能问题便是过早优化-万恶之源。

使用线程是为了调整性能，线程不是降低而是提高了全局复杂度。因此，除非万不得已，尽量避免使用线程。

  • 基于线程的程序不仅产生普通的竞争问题，而且产生了新一类 bug：时许依赖，要重现这些问题都极其困难，遑论修复。

#7.2 Unix IPC 方法的分类

在使用更晚出现、更复杂的激发前，应当通过实证——用原型和基准检测结果——所有更早出现、更简单的技法都不管用。