序

知识和专能差别巨大，凭借知识可以推断出该做什么，而专能能让你在无意之间条件反射的把事情做好。

Advanced Programming in the Unix Environment [Stevens92] 是探究Unix API的经典著作

The Practice of Programming [Kernighan-Pike99] 是每个程序员都应该看的书

Zen Flesh, Zen Bones [Reps-Senzaki] 禅宗

用错误的方式解决正确的问题总比用正确的方法解决错误的问题。　－－Doug Mcllroy

哲学

Unix 仍然是唯一一个在不同种类的计算机，众多厂商，各种专用硬件上提供了一个一致的，文档齐全的应用程序接口的操作系统。

每个程序就做好一件事。如果有新任务，就重新开始，不要在原程序中加入新功能而搞得很复杂。
假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
尽可能早地将设计和编译的软件投入试用，哪怕是操作系统也不例外，理想情况下，应该是在几星期内。对拙劣的代码别犹豫，扔掉重写。
优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事必先利其器。

Unix哲学：一个程序只做一件事，并做好。程序要能协作，程序要能处理文本流。这是最通用的接口。

Rob Pike认为Unix的哲学：

你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方修改代码，除非你已经证实那里就是瓶颈所在。
估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。
花哨的算法在n很小的时候通常都很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）
花哨算法比简单算法更容易出bug，更难实现。尽量使用简单的算法配合简单的数据结构。
- 拿不准就穷举
数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。
没有原则6

Unix哲学基础

整体上来说：

模块原则：使用间接地接口拼合简单的部件
- 降低整体复杂度
清晰原则：清晰胜于机巧
- 优雅而清晰的代码不仅不容易崩溃，更易于让后来的修改者立刻理解
- 永远不要吃力的解读一段晦涩的代码三次
组合原则：设计时考虑拼接组合
- 根据不同的需求粘合使用不同的接口
分离原则：策略同机制分离，接口同引擎分离
- 探索新策略时不需要打破机制
简洁原则：设计要简洁，复杂度能低就低
- 设计能力大大超出实现和排错能力，结果便是代价高昂的废品
- 以简洁为美
吝啬原则：除非却无他法，不要编写庞大的程序
透明性原则：设计要可见，以便审查和调试
健壮原则：健壮源于透明和简洁
- 透明化和简洁化，程序内部逻辑便于理解，更健壮
表示原则：把知识叠入数据以求逻辑质朴而健壮
通俗原则：接口设计避免标新立异
- 最少惊奇原则
- 能够缓和学习曲线
- 最小立异原则另一面，要避免表象相似，实际却略有不同
缄默原则：如果一个程序没什么好说的，就沉默
- 一切从简，沉默是金
- 设计良好的程序将用户的注意力视为有限的宝贵资源
补救原则：出现异常时，马上退出并给出足够错误信息
- 宽容的收，谨慎的发。
- 考虑宽容性，而不是纵容的实现来补救标准不足
经济原则：宁花机器一分，不花程序员一秒
生成原则：避免手工hack，尽量编写程序去生成程序
优化原则：雕琢前先要有原型，跑之前先学会走
- 过早优化是万恶之源
- 匆忙优化可能是比乱加功能更损害设计的错误
- 过早优化实际上会妨碍全局优化
- 优化之前先保证能用
多样原则：决不相信所谓的“不二法门”的断言
扩展原则：设计着眼于未来，未来总比预想来的要快
- 要为数据格式和代码留下扩展空间，改变的同时保证兼容性