不懂Unix 的人注定最终还要重复发明一个蹩脚的Unix。
1. 前言
是在年初逛知乎的时候知晓这本书的存在的，看到有个答主在计算机类的话题下多次推荐并引用了书中的一些观点，留下印象比较深刻的有"宁花机器一分，不花程序员一秒"，“雕琢前先得有原型，跑之前先得学会走”这两个。
当下的时间节点被作为常识看待的两个观点，出现在一本出版于2003年的书籍上，而且这本书在网上的评价相当高，那么完整看看这本书里到底讲了些什么，就成为一种必然的选择。
2. 全书印象
本书分为四部分。
- 第一部分介绍UNIX历史和哲学。为后续章节埋下伏笔。
- 第二部分针对第一部分介绍的UNIX哲学原理，从原理到实现进行了专门的讲解。
- 第三部分则介绍了UNIX下提供的各类工具，同时一并介绍了各类工具的用途，以及其背后隐含的思想。
- 第四部分揭秘UNIX高效文化背后起到顶梁柱作用的一系列人际事务和约定。
本书给我的感受，和几年前从《SICP》得到的非常类似，除了对于编程技艺本身的极致追求外，对于软件研发中人的重要性的强调，也是遍布了整本书。
3. 部分摘抄
3.1 十七条"UNIX哲学基础"
首先是作为cheetbook，这个行业内的从业者都应该融入到血液里的十七条"UNIX哲学基础"，发表至今已逾二十载，但其中的每一条都毫无褪色的痕迹：
好的，明白了！以下是全部的原则及其信息：
| 原则 | 英文名称 | 说明 | 应用建议 |
|---|---|---|---|
| 模块原则 | Module Principle | 使用简洁的接口拼合简单的部件 | 将功能划分为模块，通过简洁的接口进行通信 |
| 清晰原则 | Rule of Clarity | 清晰胜于技巧 | 命名清晰、代码易读易懂，不要为了追求技巧而牺牲可读性 |
| 组合原则 | Rule of Composition | 设计时考虑拼接组合 | 多组合，少继承 |
| 分离原则 | Rule of Separation | 策略与机制分离，接口与实现应当分离 | |
| 简洁原则 | Rule of Simplicity | 设计要简洁，复杂度能低则低 | 避免过度设计，保持代码简洁 |
| 吝啬原则 | Rule of Parsimony | 除非确无它法，不要编写庞大的程序 | 避免不必要的代码和逻辑，保持代码精简 |
| 透明性原则 | Rule of Transparency | 设计应当透明可见，以便审查和调试 | 可观测性。透明性是重用的关键 |
| 健壮原则 | Rule of Robustness | 健壮源于透明与简洁 | |
| 表示规则 | Rule of Representation | 把知识叠入数据以求逻辑质朴而健壮 | 数据驱动 |
| 最小惊喜规则 | Rule of Least Surprise | 接口设计避免标新立异 | 接口设计应当符合用户的预期，避免过于特殊和惊喜的设计 |
| 缄默原则 | Rule of Silence | 如果一个程序没什么好说的，就保持沉默 | 避免不必要的输出和提示信息，减少对用户的打扰 |
| 补救原则 | Rule of Repair | 出现异常时，马上退出并给出足量错误信息 | 快速失败 |
| 经济原则 | Rule of Economy | 宁花机器一分，不花程序员一秒 | 在保证质量的前提下，尽量使用计算机资源完成任务，减轻程序员负担 |
| 生成原则 | Rule of Generation | 对于一些固定规则的代码，可以通过自动代码生成工具或者编写抽象的高级程序来生成代码，避免手动编写程序的错误 | 提高代码质量和效率 |
| 优化原则 | Rule of Optimization | 雕琢前先得有原型，跑之前先得学会走 | 不要憋大招。先保证运行，其次正确，最后求快。 |
| 多样原则 | Rule of Diversity | 绝不相信所谓"不二法门"的断言 | 吸收并借鉴各种优秀的设计思想，不断完善自己的设计方法和风格 |
| 可扩展性规则 | Rule of Extensibility | 设计着眼未来，未来总比预想快 | 设计应当考虑未来的可扩展性。 |
全书剩下的部分基本就是用UNIX历史中出现的各类广受追捧的工具和影响甚广的错误，从正反两面的实例来论证这十七条原则的普适性和正确性。
过往看到过类似的言论：“计算机领域的日新月异的新技术犹如大海表面的波涛汹涌，而作为底层支撑的技术和原理如同海底一般波澜不惊"，本书中想要传达给读者的很明显属于后者，如果你希望在这个行业走完职业生涯，如何抉择自然不言自明。
”
职业生涯中，你会持续发现这十七条原则的 应用场景，以及因为违背它们而付出的代价。你也会在一次次的切身体会中感悟到先贤们沉淀下的智慧。
3.2 关于性能优化
作者在本书中用了专门的第十二章来向读者强调"过早优化是万恶之源"，我们要"先估量，再优化"。
过往笔者在这上面也算是踩了不少坑，尤其是在初入职场人微言轻的阶段。领导解决性能问题靠猜 —— 猜个方向去优化，然后再猜一个再优化，然后将好几个优化组合在一起打包进行测试，一个月下来整个团队身心俱疲，然后问题反而更严重了。
现在虽然有了一定的话语权，但发现即使上一级领导，依然也是个含糊的，靠感觉靠经验去猜可能是哪里导致性能出现问题，活生生一门科学给玩成了算命学。
以下是我关于传统业务型软件公司系统性能问题的一些个人看法：
- 我们所谓的性能问题 -- 把代码写好， 95%的问题就解决了，剩下的5%就是去数据库调优（例如增加索引，改进SQL语句）。
- JVM也不需要你去调优。
- "先估量，再优化"。诚如《编写高质量代码——改善Java程序的151个建议》 中所说的「性能是个大"咕咚"」，如果感觉靠谱，那么多五百万等着呢，不值得在这里上这破班。
- If You Can’t Measure It, You Can’t Improve It --- Peter Drucker
3.3 不要憋大招
十七条UNIX哲学基础中的"优化原则"同样让人有着"求道终有所得"，多年的困惑和探索终于得到认同的，热泪盈眶的感觉。
- 雕琢前先得有原型，跑之前先得学会走。
- 先保证运行，其次正确，最后求快。
- 现在得到90%，比等不来的100%更有价值。
现实的职业生涯里，身边有一些人做点事情总会困难重重 —— 哎呀，这个地方不太行，那个地方还得打磨打磨，这个地方这么写可能会有性能问题。总而言之就是交代点事情出结果时候总是很难产，更要命的是千呼万唤之下，最终出来的“更优秀的作品”很少有达到所宣称效果的，相较于所额外投入的资源，所谓的改进不仅乏善可陈，更可能是闭门造车下导致的无谓"优化"。
先以最快的速度出个V1版本让相关方看到，然后在此基础上，根据相关方的建议以及自己的思考，迅速迭代出V2版本，以及之后的V3版本，其实这就是最近十余年备受追捧的MVP理念。
正如《进化——从孤胆极客到高效团队》所言，闭门造车不适合软件研发这个行业，也正如"多样原则"所说的，一个需求不可能只有一种实现方式，重要的是找到正确的需求，而正确的需求只能从使用者那里获得，不是闭门造车，关起来门想出来的。
3.4 代码越少，产生的问题越少
没想到一本出版于几十年前的书点明了我心中的困惑。
本书中的观点“一个软件中的问题量多少，与语言关系不大，而和代码行数正相关。也就是代码越少，可能的问题越少”
细细想来，所谓的高级语言，除了更符合人类的认知习惯，降低人类理解时候的认知负担外，其另外一个显著特点就是在实现同样的业务功能时，所需要的代码量更少。
简单就是美。
3.5 重要的是人
正如上面小节里已经提到了的，本书给我的最大一个感受就是对于人本身的关注。
这些关注体现在我们应该怎么样组织信息来降低门槛，让人处理起来更为轻松，节省人的时间和精力。
例如以下这些出现在书中的观点，最终都是为了人本身：
- 可显性降低入门门槛，透明性则减少代码中的存在成本。这句位于本书第134页底部引用区的短句，不需要过多解释就可以看出隐含的主角依然是人。降低的是人类的入门门槛，减少的是人类为了理解代码所投入的成本，也就是代码中的存在成本。
- 书中的第十章关于配置的建议，核心思想之一就是“配置应用能够被人阅读并且可以用常规的文本编辑器修改”。另外就是配置项内容的排版建议也是处处透露着要最大化减少人的注意力消耗。
- 另外诸如"模块化，透明性,紧凑性"等等，也都无一不是在于此。
4. 我们能赢，只要我们想赢
整本书看下来，最让人动容的居然是最后第20章，最后的那个小节"20.5 UNIX文化中的问题"。
在这个小节里，作者直面了UNIX文化中的"清高/精英"姿态，坦言UNIX众需要认真考虑站在"普通用户角度思考"的问题了，学习其他操作系统的交互设计。
然后就是最后的那句："我们能赢，只要我们想赢"。
