重用：论不要重新发明轮子 透明性是重用的关键 从重用到开源 可移植性 文档：向网络世界阐释代码 开放源码：在Unix新社区中编程 源码公开 尽早发布，经常发布 给贡献以表扬 未来：危机与机遇 附录：无根的根：无名师的Unix心传 无名师与万行码 无名师曾对来访的程序员说：“Unix传统上认为，一行shell脚本胜过万行C程序。” 这个程序员自以为对C极其精通，说：“这不可能。UNIX内核 …

优化 关于性能优化，最重要就是如何知道何时不去优化。最有效的优化往往是优化之外的其他事情，比如清晰干净的设计 什么也别做，就站在那儿 别去优化一个工作中的系统，集中精力将时间复杂度或空间复杂度从指数级降到对数或常数集。 另一个建设性的“无为”方式就是不写代码。 先估量，后优化 有真凭实据证明应用程序运行缓慢，这时候（仅当此时）才可以考虑优化代码。但付诸实施前，要先估量。 …

Unix环境下的用户接口设计模式 在Unix接口设计的传统中，涉足两个主题。一个与其他程序通讯方式的前瞻性设计；另一个是最小立异原则 最小立异原则 最小立异原则：“少来标新立异”是所有设计中的通用原则，且并非仅局限于软件设计。 如果有可能，尽量允许用户将接口功能委派给熟悉的程序来完成。 不能委派，那就效仿。目的减少用户在使用时必须学习的复杂过程。 接口设计评估 简洁、表现力、易用、透明 …

Unix配置 经验法则： 提高适应能力，除非这样做会产生超过0.7秒的延迟。0.7秒是一个魔数，人们几乎察觉不到少于0.7秒的启动延迟。 用户不应该看到优化开关。让程序经济运行时设计者的任务，不是用户的任务。与提高界面复杂度成本相比，让用户从优化开关来获取那点儿性能收益，换来界面复杂度的提升，往往得不偿失。 能用脚本包装器或简单管道实现的任务，就不要用配置开关实现。能简单利用其它程序来完成的任 …

多道程序设计：分离进程为独立的功能 实现子进程方式： 降低进程生成的开销。 提供方法（shellout、I/O重定向、管道、消息传递和套接字）简化进程间通信。 提倡使用能由管道和套接字传递的简单、透明的文本数据格式。 UNIX IPC 方法的分类 把任务转给专门的程序 管道、重定向和过滤器 管道依赖的约定，每个程序一开始有两个I/O数据流可用：标准输入和标准输出。许多程序都可写作过滤器， …

文本化 设计将应用数据存储在永久存储器中的文件格式在协作程序中（可能通过网络）传递数据和命令的应用协议 数据文件元格式 为了简化存储的序列化操作发展得来。 DSV风格 RFC822格式 Cookie—Jar格式 Record—Jar格式 XML WindowsINI格式 Unix文本文件格式的约定 应用协议元格式 简化网络间事物处理的序列化操作发展得来。 HTTP BEEP …

模块性 保持清晰，保持简洁 Unix 重视模块化、正交性和紧凑性问题。 封装与最佳模块大小 封装良好的模块不会过多的向外部暴露自身的细节，不会直接调用其他模块的实现码，也不会胡乱共享全局数据。 模块之间通过应用程序编写的接口（API）— 一组严密、定义良好的程序调用和数据结构来通信。 API在模块间扮演双重角色。在实现层面，作为模块间的滞塞点组织各自的内部细节被相邻模块知晓；在设计层 …

UNIX哲学 原则1：你无法判断程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急与胡乱这个地方改代码，除非你已经证实那儿就是瓶颈所在。 原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。 原则3：花哨的算法在n很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）。 原 …