《Linux/Unix设计思想》读书笔记与感想

英文名：Linux and the Unix Philosophy

作者：Mike Gancarz    翻译：漆渀（ben）

NIH - Not Invented Here

准则1：小既是美                                                        SMALL

• 易于理解、维护
• 消耗的系统资源较少
• 易于与其他工具相结合

准则2：让每一个程序只做好一件事                            1THING

准则3：尽快建立原型                                                 PROTO

• 原型的建立是学习的过程
• 建立早期原型能够降低风险

准则4：舍高效率而取可移植性                                   PORT

• 最高效的方法通常不可移植
• 好程序永远不会消失
• 不要过度优化，下一代硬件会更快
• 可移植性减少了用户的学习时间

准则5：采用纯文本文件来存储数据                            FLAT

• 通用性强
• 易于阅读和编辑

准则6：充分利用软件的杠杆效应                               REUSE

• 可重用性
• 良好的程序员编写优秀代码，优秀的程序员借用优秀代码

准则7：使用shell脚本来提高杠杆效应和可移植性      SCRIPT

• 抵制使用低级语言重写脚本的冲动

准则8：避免强制性的用户界面                                  NOCUI

• 难以与其他小程序结合

准则9：让每一个程序都成为过滤器                           FILTER

• 程序不创建数据，只转换数据

十条小准则：

1. 允许用户定制环境                                               custom                           
2. 尽量使操作系统内核小而轻量化                          kernel
3. 使用小写字母并尽量简短                                     lcase
4. 保护树木                                                             trees
   
5. 沉默是金                                                             silence
   
6. 并行思考                                                             parallel
7. 各部分之和大于整体                                            sum
8. 寻求90%的解决方案                                            90cent
9. 更坏就是更好                                                      worse
10. 层次化思考                                                          hier

人类创造的三个系统的特点     

第一个系统

• 背水一战，没有足够时间
• 个人或小团队开发
• 精简、其貌不扬
• 可接受的性能、几乎没有华而不实的特性、拥有激动人心的概念
  

第二个系统

• 专家使用“第一个系统”验证过的想法来创建“第二个系统”
• 由委员会设计
• 往往臃肿而缓慢
• 被大张旗鼓地誉为伟大的成就，往往受到关注，得到商业上的成功

第三个系统

• 往往由为“第二个系统”所累的人们创建
• 通常会改变名称
• 最初的概念保持不变并显而易见
• 结合了“第一个系统”和“第二个系统”的最佳特性
• 时间充裕

Linux处于第二与第三个系统之间

“永远都没有做完的软件，只有发布的软件。”

“计算机世界中存在一种主流思想学说，认为良好的设计应该具备4个特点：简洁性、正确性、一致性和完整性。在能被察觉到的层面上，设计应该是简单、正确的（没有bug），它的主体思想应当贯穿始终并具备完整性，也就是能够涵盖人们预期到的所有合理情况。”

                                                                                                                       ——7.9 更坏就是更好 

"雅达利的做法就好像他们认为如果给每个人都发把枪，那很有可能会有人射中自己的膝盖。相比之下，Unix系统的做法却像是给门外汉发了一把冲锋枪，并装上20发子弹对准了自己。"

                                                                                       ——9.1 雅达利家用电脑：人体工程的艺术

    刚开始读这本书的时候，会读得比较快。使用了近四年的Linux系统，对其设计思路和原则有一定的体会，这本书算是把我难以描述或者较为模糊的理解总结了出来。读了将近一半后，阅读速度就变慢了，或者说兴趣变淡了，因为总觉得书的后半部分将之前的话重复了一遍又一遍，而且有些例子与对比本人觉得有些牵强，也许是我不能理解吧......

    关于书中提到的9+10条准则，有些是在使用中确实能实实在在体会到的，而有些笔者则觉得应该加个前提条件才更为合适。

    SMALL、PROTO、REUSE、90cent这几条原则在软件设计中确实有着较为广泛的适用性。

    公司使用的bugzilla系统有那么一句话，大意是：“软件要么简单到明显没有缺陷，要么复杂到没有明显的缺陷”。过于庞大、复杂的系统确实是令人头疼的，即便是有经验的工程师也很难将每一个细节完全掌握，更多是从宏观进行把控。而这种把控往往要将软件系统划分为若干层次、模块，然后投入人力进行维护。如果划分合理，设计优雅的话，每一个模块的维护者直接打交道的对象又变为一个个“小而美”的子程序。

    关于原型设计问题，笔者最初的体会是在读书时实习的公司的一位软件总监身上体会到的。那时的我，看过一些代码，实践经验极度匮乏，所以谈什么设计，都是扯淡，现在看来更是可笑。这位领导和我的性格完全相反。他喜欢易用的语言，习惯先把东西做出来在进行讨论或进一步设计，而我则先查阅各种资料，寻找着各种近似与标准化、公式化的解决方式，然后美其名曰“设计”。记得在一个IO相关问题的处理上，我纠结于使用阻塞还是非阻塞方式，后来和这位领导谈了一次，他说不要想这么多，先做一版出来再说吧。的确，两种方式都是书上看来的，都是纸上谈兵，二者带来的具体效果和影响都没有具体的认知，或者说，二者的本质区别我很难清楚的讲出来。既然这样，当然最好的处理方式是使用能想到的方式去分别实现需求，在想想如何设计几条case进行测试，然后选择最为合理的方案继续推进。这才是学习的方式，也是茫然时的一种选择方式。

    下边就谈谈关于可移植性和杠杆效应问题。书中说的舍高效率选择可移植性，个人认为在一些低成本的嵌入式系统中，不完全适用。虽然明天的硬件会更快更便宜，但是面对当前的激烈市场竞争，通过技术手段降低成本是一个工程师应该考虑的，而这种考虑的结果往往是牺牲可移植性。另一方面，软件设计时的各种分层，各种框架设计，无非就是为了解偶，解偶的目的则是增加可移植性，而这又是PORT原则的体现。拿现在智能设备的应用来说，一款移动app如何才能通吃若干智能系统？分别做开发应该是能想到的最笨的办法了，而且不利与产品的长期发展和演进，后期的维护成本可能会很高。所以，常见的一种解决方案是使用较为通用的语言设计不依赖于特定平台的功能性框架，对于无法独立与平台的部分，增加一个适配层，最后上层UI则使用相应平台的语言进行开发，最后使用两种语言的调用接口进行粘合。关于代码的可重用性，一方面是设计时要考虑自己代码的可重用性，另一方面，对于重用别人的代码，也不是件简单的事，这也需要使用者有足够的能力辨别代码是否有价值进行重用。

    总体来说，笔者很喜欢Linux系统，但是没有上升到哲学或者意识形态的程度。本人七年前买的笔记本现在只有装Linux才能流畅运行，所以近期多数时候在使用Linux。Linux确实是适合开发的操作系统，一旦熟悉了相应发行版的包管理系统，使用起来就会方便许多。更重要的是，如果能按照Linux的思想进行开发（编辑器 + 编译工具链），每一个细节都会暴露出来，无论是学习还是开发，都比使用集成开发环境看得要透彻。Shell脚本结合各种古老而强大的小工具，能使很多重复劳动自动化，在服务器上，这个特点更为明显。管道、重定向、一切都是文件，这些使用使用Linux就不得不知道的思想，每天都在被使用。一行中若干个shell命令使用管道相连，一下子就能得到想要的结果，这正是“每一个程序都是过滤器”的体现。

    如果你是一个爱“折腾”的人，就来试试Linux吧！