关于Unix哲学

作者: 阮一峰

日期: 2009年6月18日

先讲两个很老的小故事。

第一个故事。

有一家日本最大的化妆品公司,收到了用户的投诉。用户抱怨买来的肥皂盒是空的。这家公司为了防止再发生这样的事故,很辛苦地发明了一台X光检查器,能够透视每一个出货的肥皂盒。

同样的事故,发生在一家小公司。他们的解决方法是买一台强力的工业电扇,对着肥皂盒猛吹,被吹走的就是空肥皂盒。

第二个故事。

美国太空总署(NASA)发现在太空失重状态下,航天员无法用墨水笔写字。于是,他们花了大量经费,研发出了一种可以在失重状态下写字的太空笔。猜猜看,俄国人是怎么解决的?(答案在本文结尾处。)

=====================

这几天,我在看Unix,发现很多人在谈"Unix哲学",也就是开发Unix系统的指导思想。

Wikipedia上列出了好几个版本,不同的人有不同的总结。发明管道命令的Doug McIlroy总结了三条,而Eric S. Raymond则在The Art of Unix Programming一书中,一口气总结了17条(英文版中文版)。

但是我发现,所有人都同意,"简单原则"----尽量用简单的方法解决问题----是"Unix哲学"的根本原则。这也就是著名的KISS(keep it simple, stupid),意思是"保持简单和笨拙"。

下面就是我对"简单原则"的笔记。如果你想最简单地完成一项编程任务,我认为可以从四个方面入手:

1. 清晰原则。

代码要写得尽量清晰,避免晦涩难懂。清晰的代码不容易崩溃,而且容易理解和维护。重视注释。不为了性能的一丁点提升,而大幅增加技术的复杂性,因为复杂的技术会使得日后的阅读和维护更加艰难。

2. 模块原则。

每个程序只做一件事,不要试图在单个程序中完成多个任务。在程序的内部,面向用户的界面(前端)应该与运算机制(后端)分离,因为前端的变化往往快于后端。

3. 组合原则。

不同的程序之间通过接口相连。接口之间用文本格式进行通信,因为文本格式是最容易处理、最通用的格式。这就意味着尽量不要使用二进制数据进行通信,不要把二进制内容作为输出和输入。

4. 优化原则。

在功能实现之前,不要考虑对它优化。最重要的是让一切先能够运行,其次才是效率。"先求运行,再求正确,最后求快。"(Make it run, then make it right, then make it fast.)90%的功能现在能实现,比100%的功能永远实现不了强。先做出原型,然后找出哪些功能不必实现,那些不用写的代码显然无需优化。目前,最强大的优化工具恐怕是Delete键。

==================

答案是,俄国人用铅笔。

(完)

珠峰培训

stuQ

留言(55条)

不可能是用铅笔的,铅笔如果断裂的话有很大的危险。具体去看新语丝那里有一篇专门的科普文章。

引用blackgun的发言:

不可能是用铅笔的,铅笔如果断裂的话有很大的危险。具体去看新语丝那里有一篇专门的科普文章。

而且铅笔书写之后会有导电的粉尘,估计太空仓那个环境不允许。

http://www.scientificamerican.com/article.cfm?id=fact-or-fiction-nasa-spen

在太空中使用铅笔是很危险的,外面包的木头易燃,石墨及其细粉导电。

引用s7evenz的发言:

http://www.scientificamerican.com/article.cfm?id=fact-or-fiction-nasa-spen

在太空中使用铅笔是很危险的,外面包的木头易燃,石墨及其细粉导电。

我真鄙视你的IQ,太空怎么个燃烧啊。还是您提供了助燃剂

阮兄,你火星了。

這兩個故事都已被證明是編的有窮多年了。

哈哈哈,大家还是看UNIX部分吧,不过我很惊喜,有发现一个
伪科来

引用深海的发言:

我真鄙视你的IQ,太空怎么个燃烧啊。还是您提供了助燃剂

拜托,有道理讲道理,不要道理还没讲,就BS别人。

太空是没法子烧,太空舱呢!你见过谁谁谁出舱后揣根铅笔吗?

再说,即使你想说某人智商低——拜托,“你BS他”能说明什么问题?你是不是想变相的证明自己是个天才?

关于两个小故事就不说了,多Google几下就知道了。
关于编程的原则,实际上考虑下背后的原因,只有一条:成本。
由于代码大部分的时间是在被读,简单容易被理解,所以这是最好的减少成本的手段。


  早期的宇航员都使用铅笔,并不是因为接受了小学生的建议,而是因为钢笔、圆珠笔在失重条件下都无法使用,铅笔是惟一的选择。但是铅笔笔芯有时候会断,在失重的环境中飘浮,会飘进鼻子、眼睛中,或飘进电器中引起短路,成了危险品。此外,铅笔的笔芯和木头在纯氧的环境中还会快速燃烧。

  因发明了圆珠笔通用笔芯而发了大财的保罗·费舍尔,意识到宇航员使用安全、可靠的书写工具的迫切性,自掏腰包进行研制,花了两年时间和两百万元费用后,于1965年研制成了能在太空环境下使用的圆珠笔———太空笔。其原理很简单,采用密封式气压笔芯,上部充有氮气,靠气体压力把油墨推向笔尖。经过严格的测试后,太空笔被美国宇航局采用。1967年12月,费舍尔以每枝2.95美元的价格把400枝太空笔卖给美国宇航局。

  1969年7月20日,太空笔跟随阿姆斯特朗和奥尔德林上了月球,并救了他们的命。阿姆斯特朗和奥尔德林在月球表面完成历史性漫步,回到登月舱准备离开时,发现发动机的塑料手动开关被宇航服的背囊碰断,无法启动发动机向地面指挥中心求援。他们需要拨动开关中一个细小的金属条,为了减轻重量,他们已抛弃了所有的工具。地面指挥中心的一名工程师灵机一动,建议他们用太空笔试试。奥尔德林掏出太空笔,缩回笔芯,用笔的中空尾端拨动了开关,成功地启动了登月舱的发动机。

  太空笔是全天候的圆珠笔,除了太空环境,还可在其他各种极端恶劣(如寒冷的高山上和深海底)的条件下使用,如油污、潮湿、粗糙、光滑的表面,并适用于各种角度书写,使用寿命长达几十年,深受登山运动员、户外活动者、技工、士兵、警察的欢迎。目前在美国市场上8美元即可买到一枝最简单的费舍尔太空笔。

顺便给出这篇太空笔文章的链接吧,犯过这个错误的人还不少。
http://www.xys.org/xys/netters/Fang-Zhouzi/sohu/spacepen.txt

引用s7evenz的发言:

http://www.scientificamerican.com/article.cfm?id=fact-or-fiction-nasa-spen

在太空中使用铅笔是很危险的,外面包的木头易燃,石墨及其细粉导电。

发现这里竟然有看SciAm的朋友,哈哈。

阮兄文中语:(Make it run, the make it right, then make it fast.)
中的the是否应为then?

风扇那个太假了,商业应用不可能使用这种低可靠性,低控制性的方案.特别是流水线上.

引用伍岭的发言:

阮兄,你火星了。

這兩個故事都已被證明是編的有窮多年了。

谢谢大家的批评,真惭愧啊。

我承认故事不科学,我本人也不够严谨,以后一定吸取教训。

如果这些故事不是错的,倒真的是证明这篇文章的主旨“Keep it simple, stupid”的好材料。

引用Lin的发言:

阮兄文中语:(Make it run, the make it right, then make it fast.)
中的the是否应为then?

谢谢指出,已经更正了。

"Keep it simple, stupid"似乎也翻译错了。我理解的意思是:保持简单,笨蛋。

引用chuan的发言:

"Keep it simple, stupid"似乎也翻译错了。我理解的意思是:保持简单,笨蛋。

我的理解,stupid应该是类似傻瓜相机的那种意思,简单的傻瓜都能弄懂. “笨拙”总觉得有点那个,unix可谈不上笨拙,相反是很灵巧的说

关于之前的小故事,我的看法可能比较不一致。
实际上,这个是没有高下之分的。
不同的人解决问题的思路和方法都不同
但是过度宣传小聪明是不可取的。

KISS is what I learned from Microsoft

KISS is keep it short and simple.
keep requriment short and simple, keep coding short and simple

引用深海的发言:

我真鄙视你的IQ,太空怎么个燃烧啊。还是您提供了助燃剂

你该不会认为他们是太空漫步的时候用铅笔吧?去翻翻宇航员在太空中的图片,在太空舱里是有氧气的。

KISS的全称有很多不同的写法,Keep it simple and short是很常见的一种,意义上也最完整。

而keep it simple,stupid是一个比较戏虐的说法了。你看,并不是keep it simple and stupid,所以,阮一峰的翻译并不对。

另外,这几乎是现代所有软件设计的principle,并非UNIX所独有。不过什么是simple and short,显然微软,苹果,UNIX各有不同的理解,这主要还是由于各自营造的生态系统不同。

先求运行,再求正确,最后求快。”(Make it run, then make it right, then make it fast.)

这也就是敏捷先驱Kent Beck的TDD(测试驱动开发)中提到的节奏。更好术语化一点就是:不可运行->可运行->重构。

1.故事不足为信,用之前简单google一下就能得到很多提示。尤其写这种“有教育意义”的博文的时候,还是战战兢兢一点好。
2.故事即使是真的,也不足以拿来讲道理。这是中国式思维方式的毒瘤,哪跟哪啊,你证明了他们足以类比吗?非常反感这样的思维/论证方式。中国几千年没有出现科学绝不是偶然的。必须彻底认识这种强盗式思维/论证方式的弊病。

下面是我对Unix Phiosophy的看法。和博主讨论一下。我的观点基本上是相反的。
我认为Unix并不指导用户怎么去解决问题,这不是OS应该关注的。
如果OS希望指导用户怎么去解决问题,是对用户的不尊重--一如Windows。Windows的逻辑是"我发明一个功能,你看多好啊,(感激我吧!),来让我教教你怎么用,先点这个,再点那个,找出这个菜单,点出那个对话框,找到Tab,选项的意思是。。。 看看,我们的新功能给你带来了多大的好处啊。。。(比如你点击20次后终于可以把垃圾箱从桌面上去掉了)“这是WIndows的逻辑:发明功能,教育用户.

The.UNIX.Philosophy一书对Unix哲学有一些总结,最根本的一条是”small is beautiful".
其实这后边的思路是“free the user",给用户自由。我认为包括方法论上面的自由。

博主讲的其实另一方面,不是UNix的哲学,而是Unix实现的哲学。当然对于在UNIX上开发的程序员来说,最好也遵循UNIX开发中带来的哲学,但不绝对。更多的恐怕是博主自己的倾向.

这两个故事 在博客园狠狠的活了一把


说这个是 博士 于 小工 谁有用的问题。 呵呵。。。

同意 daryl 的说法。

Unix 是站在研发者的角度实现的系统,从使用者角度上手还是复杂了些。

必须彻底认识这种强盗式思维/论证方式的弊病。

这种思维比较认同。这犹如是读者改头换面的思维方式。

引用yabo的发言:


关于编程的原则,实际上考虑下背后的原因,只有一条:成本。
由于代码大部分的时间是在被读,简单容易被理解,所以这是最好的减少成本的手段。

代码大部分的时间是在被读,先不说开不开源,就现在程序员和用户差异愈来愈大,难道你指望用户打来投诉电话的时候告诉他去看源代码.

引用daryl的发言:
…… 如果OS希望指导用户怎么去解决问题,是对用户的不尊重--一如Windows。 …… 这是WIndows的逻辑:发明功能,教育用户.
不认同。

OS控制硬件是本分,能指导引导用户尽快上手、体验友好是进步。

商场餐馆里的服务生与导购的热情服务,体现的是对客户的尊重。
倒是很多部门和单位的公务员大爷们,冷冰冰的爱答不理,体现了对纳税人的不尊重。

---故而,普通用户早就把命令行抛弃了,迷恋命令行的思维只适合为技术人员服务,对普通用户来说,开句玩笑:用户就是爷,爷用OS是为爷服务的,不是爷为OS服务的,爷不舒服,就不买单。

ps: windows server2008时就已经有命令行shell安装方式了:“Windows Server 2008 Core”

还有一个故事,是我喜欢讲给程序员听的:

美国和苏联分别是如何设计太空舱的空调的,美国人的设计:1、数字式仪表版显示温度,2、两个按钮,加温和降温,3、通过复杂的电路控制冷气和暖气的平衡达到控温目的。苏联人的思路:1、指针式机械温度计,2、两个阀门,一个控制冷气大小,一个控制暖气大小,3、发现温度过高,关小暖气,开大冷气,发现温度过低,关小冷气,开大暖气。

从舒适性来说,第一种好,从可靠性和节省成本,降低重量来说,第二种好。

个人觉得博主最后说的4条是没有问题的,实际上现在已经不再那么重视细节上的技巧带来的效率了,相对的是,可读性的地位越来越高,原因主要是两方面:

1 硬件性能和编译器优化技术的提高,甚至有的情况下现在写“简单”代码编译器更容易优化。

2 软件工程越来越大,牺牲可读性带来的效率提升给工程带来的负面风险和隐性成本过大。

面向对象理论、Java/C#等中间代码的提出和实现,本身就是以牺牲性能来提升模块化和可读性的例子。

KISS在wikipedia上的解释比较靠谱,不应该是简单和笨拙,简单肯定是对的,但是为什么要笨拙?
http://en.wikipedia.org/wiki/KISS_principle
Keep it simple,stupid!前面一个simple是指it,也就是做的事情,后面一个stupid,大概是骂不能保持事情简单的人是笨蛋吧,哈哈

我想说明一下,keep it short & simple 并非要求少写代码,而是要求你的代码简单易懂。

比如,这三种写法,哪种是 KISS 呢?

1) if (a>b) return true; else return false;

2) return a>b? true: false;

3) return a>b;

可读性和性能并不冲突.
翻阅无数经典C code 你会发现 这并不相悖的.
只是一般的程序员很难做到.至少在中国能把注
释写到代码里就算不错的了.

引用雪人的发言:

普通用户早就把命令行抛弃了,迷恋命令行的思维只适合为技术人员服务,对普通用户来说,开句玩笑:用户就是爷,爷用OS是为爷服务的,不是爷为OS服务的,爷不舒服,就不买单。

请勿YY 用户永远是 案板上的肉.

Windows vs. UNIX/Linux 永远不会有结果的,喜欢Windows的和喜欢UNIX的根本有不同的思维方式。

引用雪人的发言:

---故而,普通用户早就把命令行抛弃了,迷恋命令行的思维只适合为技术人员服务,对普通用户来说,开句玩笑:用户就是爷,爷用OS是为爷服务的,不是爷为OS服务的,爷不舒服,就不买单。

ps: windows server2008时就已经有命令行shell安装方式了:“Windows Server 2008 Core”

主要是用户的定义问题,普通家庭用户谁用unix看电影,而unix的普通用户就是技术人员,用命令行要比GUI效率高,不然微软干嘛发明PowerShell

引用yucca的发言:


代码大部分的时间是在被读,先不说开不开源,就现在程序员和用户差异愈来愈大,难道你指望用户打来投诉电话的时候告诉他去看源代码.

我会回来看评论,自己也没想到,或许今天比较空。 yucca会这么说,大概是自己没改过代码吧。别人的代码,或者自己以前写的 代码,修改之前要干什么?不要告诉我不需要读代码;不要告诉我读代码的时间可以忽略不计。如果这些都需要讨论的话,你和写代码的人沟通是极不流畅的。说到底,程序是思维的产物,代码是程序员思维的表达,写给机器只要能运行就行了,写给人看却要以方便看懂为第一重点。 关于我的观点就解释至此。 yucca会有这样的疑问,老实说不大好理解,请问是在做客服工作吗?任何思维作品都注定是给某一部分人看的。我想这很好理解——没有人会认为数学论文必须让小学生看懂,芯片设计要让画家觉得美。代码是写给程序员看的,需要让客户看懂的,叫用户手册。 想想并没有什么回复的理由,但当成训练脾气也就心平气和了。


阮。

我是个高中生、学习美术,
有一次搜索“梵高”的资料时,来到你的博客。

你知识面、真的很广。
有些都是我不能理解的。

但是、我还是愿意待着这,一点点翻阅着。

关于摄影、电影、文学、美术。

我很喜欢。

谢谢你给我的平台。

为什么要用铅笔呢。我觉得用复写纸就可以了。根本不需要考虑用什么笔。

引用张昭的发言:

我想说明一下,keep it short & simple 并非要求少写代码,而是要求你的代码简单易懂。

比如,这三种写法,哪种是 KISS 呢?

1) if (a>b) return true; else return false;

2) return a>b? true: false;

3) return a>b;

呃...莫非张昭的答案不是3?

引用张昭的发言:

我想说明一下,keep it short & simple 并非要求少写代码,而是要求你的代码简单易懂。

比如,这三种写法,哪种是 KISS 呢?

1) if (a>b) return true; else return false;

2) return a>b? true: false;

3) return a>b;

在我看来这些都是简单的. 我想KISS指的是整体架构上的清晰明了,而不是少打几次键盘这样的琐碎细节.

不幸的是,文中举得两个例子都是假的。
现实世界实际上需要越来越复杂的技术来支撑。
我过去时KISS的疯狂信奉者,现在已经不是了。
实际上“必要的”复杂,远比简单更适合这个世界。

To 小车:
你说的很有道理。

引用yucca的发言:


代码大部分的时间是在被读,先不说开不开源,就现在程序员和用户差异愈来愈大,难道你指望用户打来投诉电话的时候告诉他去看源代码.

设想"MS Word",启动时间比如说用10秒,即使你连续10000秒(大约不到3小时)使用它处理文档,但程序99.9%的时间是在等待你的命令,最终程序只运行了20秒。

MS从八十年代至今用了20年左右的时间开发"MS Office"
我估计每年至少投入200人以上,每年干200天,每天干6小时
20*200*200*6*3600=17280000000秒

雪人说
“OS控制硬件是本分,能指导引导用户尽快上手、体验友好是进步”

不同意

设想TCP/IP协议棧合四为一,上至远程文件传送方式,下至连线端口电气特性,如今有几个人还敢进行网络编程。

我认为OS的设计目标类似于硬件“稳定、高效”,OS只需要考虑程序员友好,不要今天"win16",明天"win32",后天".net",否则用户友好就是无源之水、无本之木。

还没说够

用户友好涉及心理学、行为学、领域专业知识,甚至还包括用户素质、企业文化等等方面,根本不是一个系统专家有暇顾及的,甚至也不是一个程序员能全面掌握的,需要一大批专业人士的通力合作,那种大包大揽的做法最终只能是闭门造车、纸上谈兵。

很多人总是以大众的名义,象个大爷一样,说你们搞技术的做出来的任何东西都要以我们普通人是否觉得好用来作为判断标准。这样的想法很奇怪的。

现代人类社会是分工协作的,而且分工很细致,所有人只对上面一级负责。所以OS需要对上层的程序负责,,提供很多基础函数,使得在OS上开发程序比较方便。当然OS也有界面,是被用户直接使用的,界面部分要对用户负责。

人都是懒的,但是人会分析事情,当发现对自己有用的时候就愿意花费时间去学习。电脑键盘有104个键,当你教一个人用电脑时,他会嫌麻烦,但是当你让他聊一会QQ,保证他2小时学会打字。我周围的很多同事,不会用Word,当他要一个标题,就直接设置大字体居中,而不会设置“标题1”样式;不会用多台打印机,打印只会按打印按钮,如果要选择一台非默认打印机就不会了;不会用共享文件夹,拷文件一律要登录QQ传文件。前两天我还发现,他们不会输入键盘上1234……上面的那些!@#$...符号。

如果所有公司的产品都必须对最终用户负责,那么IBM为啥要把PC业务卖掉?IBM不怎么为大众所知,但是IBM服务器、Lotus、为PS3做的芯片,哪样不赚钱?

如果我要做个产品卖给你,OK,我要考虑你是否会用的问题。但是,我为了让自己或者别的程序员工作更方便点而写了个小Python脚本,你却来指责说这个东西对普通用户没用,然后说程序员就喜欢玩专业,显摆,不贴近大众。拜托,我写这个脚本是给你们这些大众用的吗?

最近在看《走出软件作坊》,里面有一章讲的是,客户总是变更需求,导致开发成本很高,怎么办?解决的方法写了很多,但是有一点作者是绝对反对的,就是一味迎合客户,客户说要怎么改就怎么改,总把客户当老板。

单纯比较Linux、windows没啥可比性。Linux、windows也均有针对不同用户的版本。

关于编程的原则也基本认可。曾经看过一个不错的网站,年利润在千万以上,很多页面是用dw的模板功能实现的。整个网站的功能也非常简单。我觉得需求分析和实现的步骤战略也非常重要,和一峰说的第四条原则有类似之处。

阮兄的两个小故事又被外国人吐槽了:
http://pixelstech.net/article/index.php?id=1336304966

太空中的铅笔粉尘会造成灾难,苏联宇航员用铅笔只是一个段子。

四个要点写的很好!

The Art of Unix Programming 中文版链接已失效!

学习了,多谢!

太空笔的故事显然不是这样的啊。铅笔会断头还会有粉尘,后来有研发太空笔。
在《三傻大闹宝莱坞》的电影里也有讲到这笔的事。

评论区好热闹, 这段子是在三傻大闹宝莱坞看来的..

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接