总结
本书主要介绍了Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验，由公认的Unix编程大师、开源运动领袖人物之一Eric S.Raymond倾力多年写作而成
摘录：
- 用错误的方式解决正确的问题总比用正确的方法解决错误的问题好。
- Unix的这种自由放纵主义风格会让它失去很多非技术型用户。但从长远考虑，最终你会发觉这个“错误”换来至关重要的优势：策略相对短寿，而机制才会长存。
- 只提供机制不提供方针的哲学能使Unix长久保鲜
- 既然能够改编、重用、再造，节省自己 90%的工作量，为什么还要从零开始编码呢？
- 设计规则：程序得以形成严丝合缝的工具套装，而不是应景的解决对策。
- Unix哲学：
1. 原则 1：你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。
2. 原则 2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。
3. 原则3：花哨的算法在n 很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）。
4. 原则4：花哨的算法比简单算法更容易出bug、更难实现。尽量使用简单的算法配合简单的数据结构。
5. 原则 5：数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法[7]。
6. 原则6：没有原则6。 - Unix哲学中更多的内容不是这些先哲们口头表述出来的，而是由他们所作的一切和Unix本身所作出的榜样体现出来的。从整体上来说，可以概括为以下几点：
1. 模块原则：使用简洁的接口拼合简单的部件。
2. 清晰原则：清晰胜于机巧。
3. 组合原则：设计时考虑拼接组合。
4. 分离原则：策略同机制分离，接口同引擎分离。
5. 简洁原则：设计要简洁，复杂度能低则低。
6. 吝啬原则：除非确无它法，不要编写庞大的程序。
7. 透明性原则：设计要可见，以便审查和调试。
8. 健壮原则：健壮源于透明与简洁。
9. 表示原则：把知识叠入数据以求逻辑质朴而健壮。
10. 通俗原则：接口设计避免标新立异。
11. 缄默原则：如果一个程序没什么好说的，就沉默。
12. 补救原则：出现异常时，马上退出并给出足够错误信息。
13. 经济原则：宁花机器一分，不花程序员一秒。
14. 生成原则：避免手工hack，尽量编写程序去生成程序。
15. 优化原则：雕琢前先要有原型，跑之前先学会走。
16. 多样原则：决不相信所谓“不二法门”的断言。
17. 扩展原则：设计着眼未来，未来总比预想来得快。 - 软件设计有两种方式：一种是设计得极为简洁，没有看得到的缺陷；另一种是设计得极为复杂，有缺陷也看不出来。第一种方式的难度要大得多。
- 在Unix历史中，最大的规律就是：距开源越近就越繁荣。
- 养成在编码前为API编写一段非正式书面描述的习惯，是一个非常好的办法。实际上，一些最有能力的开发者，一开始总是定义接口，然后编写简要注释，对其进行描述，最后才编写代码——因为编写注释的过程就阐明了代码必须达到的目的。这种描述能够帮助你组织思路，本身就是十分有用的模块说明，而且，最终你可能还想把这些说明做成路标文档（roadmap document），方便以后的人阅读代码。
- Hatton 的经验数据表明，假设其它所有因素（如程序员能力）都相同，200 到 400 之间逻辑行的代码是“最佳点”，可能的缺陷密度达到最小。
- Hatton 建议逻辑行与物理行之间为两倍的折算率，即最佳物理行数建议应在400至800行之间。
- 无论何时，重复代码都是危险信号。
- 程序员工具箱中最强大的优化技术就是不做优化。
- 最聪明、最便宜、常常也是最迅速的性能提升方法，就是等上几个月，期望硬件性能更好。
- 如果有真凭实据证明应用程序运行缓慢，这时（仅当此时）才可以考虑优化代码。但付诸实施前，要先估量。
- 最有效的代码优化方法就是保持代码短小简单。
- 有时，按需计算出昂贵的结果，再缓存起来为以后使用，通过这种方法可以兼得鱼和熊掌（低延迟和高吞吐量）—合理利用缓存
- 代码多并不等于代码好，至少在编写低层次代码和大量重复投入时是如此。
- 评估开源软件包的方法是阅读其文档和快速浏览它的部分代码。如果所见的代码编写恰当，文档完备，那么鼓励使用。如果能够证明软件包已经有些年头并且存在实质具体的用户反馈，就可以断定它是相当可靠的（无论如何还是测测为佳）。
- 预测未来最好的方法就是去创造未来。1971年XEROX PARC会议上的发言—Alan Kay
9726
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
