Linux/Unix设计思想

最新推荐文章于 2022-05-04 23:22:59 发布

weixin_34067980

最新推荐文章于 2022-05-04 23:22:59 发布

阅读量200

点赞数

文章标签：操作系统 shell awk

原文链接：https://my.oschina.net/suyewanwan/blog/145400

版权

2019独角兽企业重金招聘Python工程师标准>>>

Unix哲学概述

1.小即是美

工作中我常常发现，想要大概解决一个问题，只需要30%左右的时间;但想要尽可能完美的解决这个问题，清除细小琐碎的bug，再多时间也不够！

假设你想编写一个将 A 文件复制到 B 文件的程序。以下就是一个典型的文件复制程序可能要执行的步骤。
(1) 要求用户输入源文件的名称。
(2) 检查源文件是否存在。
(3) 如果源文件不存在,提示用户。
(4) 询问用户目标文件的名称。
(5) 检查目标文件是否存在。
(6) 如果目标文件存在的话,询问用户是否需要替换该文件。
(7) 打开源文件。
(8) 如果源文件内容为空,提示用户。必要的话可以退出此程序。
(9) 打开目标文件。
(10) 将源文件的数据复制到目标文件里。
(11) 关闭源文件。
(12) 关闭目标文件。
文件只在步骤(10)中才真正被复制，优秀的unix程序应该只提供类似步骤（10）的功能。那其他的检查怎么办呢？让另一个unix程序取完成。然后把这些小程序组合在一起，协作完成大的功能。小程序可移植性高，易于理解和维护，对资源的消耗少。

2.让每个程序只做好一件事

这跟设计模式的“单一职责原则”一样的思想。单一职责，可以提高代码的可复用性，灵活性高。跟小即是美的思想也挺一致的（所以我觉得作者讲了很多废话啊，一些观点反反复复说来说去。）

3.尽快建立原型

这点很有必要，做出一个大概的框架，才能更有成就感，更有信心。

读书的时候指导老师说“不要赶着动手，要先写好文档，把需求说明，功能设计，详细设计等都写好了，再开始编码。在你开启编译器之前,应该确保 90%的设计已经完成。”
大体上,这些原则听起来都不错,但它们都没有给予原型足够的重视。只有建立原型,你的构想才能首先通过可视化、现实可行的方法得到验证。通过原型来提供一个关于目标的具体化表象,会得到客户认同。

有了一个具体原型,你就可以指着它说道:“产品将会是这个样子。”如果能把它演示给值得信赖的用户看看,并获得他们的反馈,你就会了解你的设计是否具有针对性了。

“ 永远都没有做完的软件,只有发布的软件。 ”这句话很经典。

4.舍高效率而取可移植性

高效率软件不会浪费 CPU 周期。它充分利用了底层硬件的特性,可往往完全忽视了可移植性的问题。它利用了一些硬件功能,如图形加速器、高速缓冲存储器以及专门的浮点指令,等等。虽然从纯粹主义者的立场而言,高效率的软件非常有吸引力。然而,可移植性意味着软件能够运行在许多不同的机器上,这使得人们考量的天平向可移植性这一端倾斜。而且，现在科技高速发展，下一（年/月/日）的硬件就会更新换代，跑的更快。可移植性的意义比高效率大得多。

在 Unix 环境中,可移植性的含义通常意味着人们要转而采用 shell 脚本来编写软件。shell 脚本附带的好处就是,比起 C 语言编写的程序,它们更具备可移植性。C程序往往要依赖头文件、计算机体系结构,以及具体 Unix 版本中一系列不可移植的特性。在 Unix 从 16 位架构移植到 32 位和 64 位的同时,大量软件曾因为 C 语言相对较低的可移植性而无法使用。

当你出于效率考量利用到一些特定硬件的功能时,你的软件就成为兜售该硬件的工具,而失去了软件自身的立场。这限制了它作为一个软件产品的能力。

5.充分利用软件的杠杆效应

无论你多么聪明过人，锐意进取，再人生的漫漫长途中，你的精力只有那么多。如果想取得非凡的成就，你就必须放大自己对这个世界的影响力。

为什么unix会越来越成功？因为它能为个体的工作发挥出巨大的杠杆效应。借用别人的成果，来实现自己的功能。通过制作衍生产品，你成倍放大了前任开发人员的努力，将他们的成果发展到新的高度;而你自己产品投资也会降低很多，因为软件的相对价值就更高。（这不就是复用代码的意义么？跟1.2点也很像啊。）

避免NIH（Not Invented Here 非我发明）综合征

我感觉自己就有NIH综合征。总是不喜欢看遗留系统的破代码，不喜欢在别人的基础上修改和完善，如果时间允许，总会从头开始编码，甚至看到我觉得能力一般的人把代码merge到我的程序中就会心里别扭。现在想来，这种想法很要不得，总是从头开始确实很浪费时间;在别人写好的基础上去重构和优化，其实更能够锻炼能力，更能够集中精力解决核心问题。

避免NIH，在原有软件的基础上进行加强和扩展是unix哲学的核心概念之一。unix的成功在很大程度上归功于一个事实：它的开发人员认为执意保留源代码的控制权并无太大必要。unix哲学的优势之一是它很重视数量众多的小命令，shell脚本是一种将他们统一在一起成为强大整体的媒介。

6.避免强制的用户界面

随着计算机技术日益成熟，存在和被感知之间的差距逐渐扩大（微型元件）。在小型事物与人的交互性变差的同时，他们之间的交互性却会大大增强。如果你只拥有小物件，你将拥有最大的灵活性，但操控它们会变得越复杂。

为了解决人们在处理数量众多的小模块时的控制复杂度，其他系统通过CUI(强制用户界面，CUI是一种与应用程序进行交互的模式，它位于系统最高命令解释器之上)，unix在这一点上和它们产生了很大分歧。

典型unix命令会努力执行自己的任务，尽量做到完全不需要人工干预。而CUI假定用户是人类，只要系统运行受到人类局限性的制约，它就不能发挥最大潜力的功效。而且拥有CUI的程序难以与其他项目相结合（因为它假定用户是人类，需要人类做出思考判断选择。）最重要的，CUI无法利用软件的杠杆效应。

7.让每个程序都成为过滤器

因为程序不会创建数据，只有人类才会创建数据。仔细想想，每个程序其实都是对数据进行筛选过滤的过程。

如果你时刻谨记所有的程序都是过滤器，拿在开发过程中就很容易避开图形用户界面。当你假设是另一个程序而不是由人来接受程序的数据流时，就能消除我们固有的偏见，即试图让应用程序具有用户友好性。你不会再局限于思考菜单的选项，而是研究数据最终可能到达的地方。尽量不要把注意力集中再程序可以做什么上面，而应该考虑程序的发展流动方向。然后，你就可以纵览全局，发现这个程序只是其中一小部分。

8.沉默是金

在没有收到任何输入数据或是没数据可输出时，许多unix命令会保持沉默。例如，ls，如果目录找不到任何文件，只会返回命令提示符：

sh>ls
sh>

许多用惯了非unix会抱怨unix没告诉用户目录是空的;但unix的拥趸者却认为ls命令拒绝打印任何信息实际上就等于告诉用户目录中没发现任何文件。虽然这种做法是为了保持简洁，但有更技术的原因，unix命令常被当做过滤器配合unix的管道机制一起使用，如：

ls -l | awk '{print $4}' | sort

如果ls没有输出，管道便裂开了，awk的进一步加工不会进行。但如果提示用户“directory：no files found”信息并输入管道，会导致sort命令的输出结果出现奇怪字符“found”。也许ls不警告用户目录为空不太友好，但它为了既告诉用户该目录为空，也能让ls用上管道机制。

9.寻找90%的解决方案

开发一个产品，可能30%的精力就完成了大多数的功能，可我们不能不花费70%的时间去修复没完没了的bug，去开发用户可能极少用到的功能。敏捷linux开发者会追求一种“低投入，高回报”的解决方案，他们会毫不留情淘汰掉很少人使用或者实现起来非常费劲的产品需求。

10.更坏就是更好

这个大家自行理解吧。打字太费劲了，头也晕了。索性留一点，意犹未尽各自体会吧。

人类创造的三个系统（相当于软件的生命周期）

人类只具备创建三个系统的能力。不管如何努力,无论为之奋斗的时间有多久,人类最终都会意识到想要打破这个规律只是徒劳。人类根本无法建立第四个系统。只有自欺欺人的家伙才不相信这个铁律。

1.第一个系统

“第一个系统”显示了一个能激发想象力的概念，能点燃参与者创意的火花。“第一个系统”是单枪匹马或是一小群人开发的。当一个小组建立“第一个系统”的时候,他们热情高昂,很快就能把事情办好。它用最小的成本获得差强人意的性能。任何与系统目标无关的事物都被排除在外。软件确实能完成它的使命——也就仅此而已。先运行起来再说。

有一点是肯定的:“第一个系统”几乎不太可能是由一大群人完成的。一旦团队规模大到影响到成员之间的日常互动交流时,工作效率就会降低,人与人之间也会产生冲突。成员们开始有着各自隐秘的日程安排。而且,在大家开始追求一己私利的同时,就会形成个人的“一亩三分地”。诸如此类事件总是会淡化系统最终目标,使其难以实现。（说的很像我之前的公司的产品。1998年几个大学生创业，写出了第一个系统;后来请架构师，优化完善增加功能，形成第二个系统。）

2.第二个系统

“第二个系统”是一个怪胎。在人类创建的三个系统中,它最受关注,而且往往会取得商业上的成功。“第一个系统”早期的成功深深地吸引了一些人,他们积极参与进来并希望将自己的名字与这个系统紧密相连,从而获得这样那样的回报。每个人都想和成功产品搭上关系。“第二个系统”是一群人参与的，所以会有诸多繁琐的流程和规范。“第二个系统”其实臃肿而缓慢，但它会被大肆宣传，它的功能有多么强大，灵活性有多好。