在第 1 章 哲学 末，将 Unix 的哲学概括为“KeepItSimple,Stupid!”。贯穿整个“设计”部分的不变主题就是尽可能保持简单设计的重要性。但什么是“尽可能的简单”?又如何断定? 本章并不是简单地尝试给出这些问题的答案，因为根本没有答案一一而是希望读者能够在概念上有所收益，从而挖掘出自己的答案。 #13.1 谈谈复杂度 #13.1.1 复杂度的三个来源 Unix 程序员追求简单的 ...

Linux 写的一篇关于 Linux 内核管理风格的文章，辛辣，又有见地，非常 Linus 个人风格的一篇文章。原文用的一些语句很微妙，虽然我已经尽可能的让翻译更通顺，但感觉失去了原文的一些风采，所以可能的话，去读原文吧。

这将是很短的一章，因为关于性能优化，Unix 的经验告诉我们最主要的就是如何知道何时不去优化。其次，最有效的优化往往是优化之外的其它事情，如：清晰干净的设计。 #12.1 什么都别做，就站在那儿 程序员工具箱中最强大的优化技术就是不做优化。 有几个理由支持这项禅式的忠告。其中一个是摩尔定律的指数效应一一最聪明、最便宜、常常也是最迅速的性能提升方法，就是等上几个月，期望硬件性能更好。 考虑到硬件和 ...

在 Unix 接口设计的传统中，会反复涉足两个主题： 与其他程序通信方式的前瞻性设计 通俗原则：接口设计避免标新立异，也可称为最小立异原则 #11.3 接口设计评估 这里的接口，指的并非是代码的 interface 而是 UI Unix 使用五种度量标准对接口风格进行分类： 简洁：一个事务处理需要的动作时间及复杂度有较低的上限，可以用点击键量，鼠标手势量和需要多少秒注意力来衡量 表现力：接 ...

#10.1 什么应是可配置的 对于问题：什么应是可配置的？ 无畏的 Unix 回答是“一切”。Unix 程序员只要可能，就建立机制而把策略决定权交给用户。这种方式产生的程序往往功能强大，专家用户用起来会非常顺手。但它所产生的接口往往选项过多，并且配置文件像杂草一样疯长，从而彻底打击了新手和一般用户。 Unix 并不打算修改这种为同行和最老练用户设计的倾向。所以，也许把问题反过来，问问“什么不应该可 ...

数据比程序逻辑更易驾驭。尽可能把设计的复杂度从程序代码转移到数据中是个好实践，选择便于人类维护和操作的数据表示法也是好实践。 #9.1 数据驱动编程 数据驱动编程有时会跟面向对象混淆起来，后者是另一种以数据组织为中心的风格。它们之间至少有两点不同。 在数据驱动编程中，数据不仅仅是某个对象的状态实际上还定义了程序的控制流 OO 首先考虑的是封装，而数据驱动编程看重的是编写尽可能少的固定代码。 # ...

Unix 有个长期传统，即包容小型的、为专门应用领域特质、大量减少程序行数的语言。

多道程序设计是设计中的荒蛮之地，几乎没有好的实践方针。许多程序员尽管精于判断如何将代码分解成子过程，然而最终还是编写出单个庞然大物般的单进程程序，而这些程序往往失败在自身的内部复杂度之上。 Unix 设计风格都运用“做单件事并做好” 的方法，强调用定义良好的进程间通信或共享文件来联通小型进程。 尽管将程序划分成协作进程带来了全局复杂度降低的好处，但代价是我们必须更多地关注在进程间传递信息和命令的协 ...

优雅的代码事半功倍：优雅的代码不仅正确，而且显然正确：优雅的代码不仅将算法传达给计算机，同时也把见解和信心传递给阅读代码的人。通过追求代码的优雅，我们能够编写更好的代码。学习编写透明的代码是学习如何编写优雅代码的第一关，很难的一关。

序列化（保存）操作有时也称为 列集(marshaling)，其反向操作（载入）称为 散集(unmarshaling)。 #文本化的重要性 文本流是非常有用的通用格式，因为人无需专门工具就可以很容易地读写和编辑文本流，这些格式是透明的（或可以设计成透明的）。