UNIX编程艺术 读书笔记 1

UNIX 编程艺术 读书笔记 1 1 哲学 Philosopy?Philosophy Matters Those who do not understand Unix are condemned to reinvent it,poorly.不懂 Unix 的人注定最终还要重复发明一个蹩脚的 Unix。--Henry Spencer 1.1 文化?什么文件 Unix 确实有自己的文化?有独特的编程艺术?有一套影响深远的设计哲学。理解这些传统?会使你写出更好的软件?即使你是在非 Unix 平台上开发。 1.2 Unix 的生命力 Unix 诞生于 1969 年?此后便一直应用于生产领域?Unix 比其它作保操作系统都更广泛地应用在各种机型上?Unix 应用范围之广简直令人难以置信? Robert Metcalf[以太网络的发明者]曾说过?如果将来有什么技术来取代以太网?那么这个取代物的名字还会叫"以太网"。因此以太网是永远不会消亡的。Unix 也多次经历了类似的转变。--Ken Thompson Unix 还引入了如今广泛采用的带目录节点的树形文件名字空间以及用于程序间通信的管道机制。 性能-时间的指数曲线对软件开发过程所引发的结果?就是每过 18 个月?就有一半的知识会过时。

Unix 并不承诺让你免遭此劫?只是让你的知识投资更趋稳定。因为不变的东西有很多?语言、系统调用、工具用法-它们积年不变?甚至可以用上数十载。而在其它操作系统中则无法预判什么东西会持久不变?有时候甚至整个操作系统都会被淘汰。在 Unix 中?持久性知道和短期性知识有着明显的区别?人们在一开始学习的时候?就能提前判断(命中率约有九成)要学的知识属于哪一类。这些便是 Unix 有众多忠实拥趸的原因。 Unix 的稳定和成功在很大程序上归功于它与生俱来的内在优势?归功于Ken Thompson,Dennis Ritchieunix编程艺术,Brian Kernighan,Doug McIroy,Rob Pike 和其他早期 Unix 开发者一开始就作出的设计决策。这些决策?连同设计哲学、编程艺术、技术文化一起?从 Unix 的婴儿期到今天的成长路程中?已经被反复证明是健康可靠的?而 Unix 才得以有今天的成功。 1.3 反对学习 Unix 文件的理由 Unix 的耐用性及其技术文化对于喜爱 Unix的人们、以及技术史家来说肯定颇为有趣。但是?Unix 的本源用途-作为大中型计算机的通用分时系统?由于受到个人工作站的围巢?正迅速地退出舞台?隐入历史的迷雾之中。

因而 Unix 究竟能否在目前被 Microsoft 主宰的主流商务桌面市场上取得成功?人们自然也存在着一定的疑问。外行常常把 Unix 当作是教学用的玩具或者是黒客的沙盒而不屑一顾?即使在 Unix 世界里?Unix 的通用性也一直受到怀疑?摇摆在危崖边?挫败这些怀疑者的不是别的?正是Linux 和其它开源 Unix(如现代 BSD 各个变种)的崛起。Unix 文化是如此的有生命力?即使十几年的管理不善也丝毫未箝制它的勃勃生机。现在 Unix 社区自身已经重新控制了技术和市场?正快速而有效地解决着 Unix 的问题。 1.4 Unix 之失对于一个始于 1969 年的设计来说?在 Unix 设计中居然很难找到硬伤?这着实令人称奇。其它的选择不是没有?但是每一个这样的选择同样面临争论?无论是 Unix 爱好者?还是操作系统设计社群的人们。Unix 文件在字节层次以上再无结构可言。文件删除了就没法恢复。Unix 的安全模型公认地太过原始。作业控制有欠精致。命名方式非常混乱。或许拥有文件系统本身就是一个错误。但是?也许 Unix 最持久的异议恰恰来自 Unix 哲学的一个特性?这一条特性是 X window 设计者首先明确提出的。

X 致力于提供一套"机制?而不是策略"?以支持一套极端通用的图形操作?从而把使用工具箱和界面的"观感"(策略)推后到应用层。Unix 其它系统级的服务也有类似的倾向?行为的最终逻辑被尽可能推后到使用端。Unix 用户可以在多种 shell 中进行选择。而Unix 应用程序通常会提供很多的行为选项和令人眼花缭乱的定制功能。这种倾向也反映出 Unix 的遗风?原本是为技术人员设计的操作系统?同时也表明设计的信念?最终用户永远比操作系统设计人员更清楚他们究竟需要什么。然而这种选择机制而不是策略的代价是?当用户"可以"自己设置策略时?他们其实是"必须"自己设置策略。非技术型的终端用户常常会被 Unix 丰富的选项和接口风格搞得晕头转向?于是转而选择那些伪称能够给他们提供简洁性的操作系统。只看眼前的话?Unix 的这种自由放纵主义风格会让它失去很多非技术型用户。但从长远考虑?最终你会发觉这个"错误"换来至关重要的优势?策略相对短寿?而机制才会长存。只提供机制不提供方针的哲学能使 Unix 长久保鲜?而那些被束缚在一套方针或界面风格内的操作系统?也许早就从人们的视线中消失了。 1.5 Unix 之得最近 Linux 爆炸式的发展和 Internet 技术重要性的渐增?都给我们充足的理由来否定怀疑者的论断。

其实?退一步说?就算怀疑者的断言正确?Unix 文件也同样值得研习?因为在有些方面?Unix 及其外围文件明显比任何竞争对手都出色。 1.5.1 开源软件尽管"开源"这个术语和开源定义(the Open Source Definition)直到 1998 年才出现?但是自由共享源码的同僚严格复审的开发方式打从 Unix 诞生起就是其文化最具特色的部分。1.5.2 跨平台可移植性和开放标准 Unix 仍是唯一一个在不同种类的计算机、众多厂商、各种专用硬件上提供了一个一致的、文档齐全的应用程序接口(API)的操作系统。Unix 也是唯一一个从嵌入式芯片、手持设备到桌面机?从服务器到专门用于数值计算的怪兽级计算机以及数据库后端都腾挪有余的操作系统。Unix API 几乎就可以作为编写真正可移植软件的硬件无关标准。1.5.3 Internet 和万维网美国国防部将第一版 TCP/IP 协议的开发合同交给一个 Unix 研发组就是因为考虑到 Unix 大部分是开放源码的。在 Internet 市场上?Unix 甚至面对 Microsoft 可怕的行销大锤也毫发无伤。互联网技术文化和 Unix 文化在 1980 年代早期开始汇合?现在已经共生共存?难以分割。

1.5.4 开源社区伴随早期 Unix 源码发布而形成的社群从未消亡-在 1990 年代早期互联网技术的爆炸式发展之后?这个社群新造就了整整一代的使用家用机的狂热黑客。今天?Unix 社区是各种软件开发的强大支持组。通过协作开发与代码复用路上艰辛的探索?才耕耘出代码共享的传统。1.5.5 从头到脚的灵活性许多操作系统自诩比起 Unix 来有多么的"现代"?用户界面又是多么的"友好"。它们漂亮外表的背后?却是以貌似精巧实则脆弱狭隘难用的编程接口?把用户和开发者禁锢在单一的界面方针下。在这样的操作系统中?完成设计者(指操作系统)预见的任务很容易?但如果要完成设计者没有预料到的任务?用户不是无计可施就是痛苦不堪。相反?Unix 具有非常彻底的灵活性。Unix 提供众多的程序粘合手段?这意味着 Unix 基本工具箱的各种组件连纵开合后?将收到单个工具设计者无法想象的功效。Unix 支持多种风格的程序界面(通常也因为给终端用户增加了明显的系统复杂度而被视为 Unix 的一个缺点)?从而增加了它的灵活性?只管简单数据处理的程序而无需背上精巧图形界面的担子。Unix 传统将重点放在尽力使各个程序接口相对小巧、简洁和正交-这也是另一个提高灵活性的方面。

整个 Unix 系统?容易的事还是那么容易?困难的事呢?至少是有可能做到的。1.5.6 Unix Hack 之趣那些夸夸其谈 Unix技术优越性的家伙一般不会提到 Unix 的终极法定、它赖以成功的原因?Unix Hack 的趣味。同 Unix 打交道?搞开发就是好玩?现在是?且一向如是。1.57 Unix 的经验别处也可适用 1.6 Unix 哲学基础 Uinx 哲学起源于 Ken Thompson早期关于如何设计一个服务接口简洁、小巧精干的操作系统的思考?随着 Uinx文化在学习如何尽可能发掘 Thompson 设计思想的过程中不断成长?同时一路上还从其它许多地方博采众长。Uinx 哲学说来不算是一种正规设计方法。Uinx 哲学(同其它工程领域的民间传统一样)是自下而上的?而不是自上而下的。Unix哲学注重实效?立足于丰富的经验。你不会在正规方法学和标准中找到它?它更接近于隐性的半本能的知识?即 Unix 文件所传播的专业经验。它鼓励那种分清轻重缓急的感觉?以及怀疑一切的态度?并鼓励你以幽默达观的态度对待这些。Unix 管道的发明人、Unix 传统的奠基人之一 Doug McIlroy 曾经说过?(i)让每个程序就做好一件事。

如果有新任务?就重新开始?不要往原程序中加入新功能而搞得复杂。(ii)假定每个程序的输出都会成为另一个程序的输入?哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。(iii)尽可能早地将设计和编译的软件设入试用?哪怕是操作系统也不例外?理想情况下?应该是在几星期内。对拙劣的代码别犹豫?仍掉重写。(iv)优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事?必先利其器。后来他这样总结道(引自《Unix 的四分之一世纪》(A Quarter Century of Unix))?Unix 哲学是这样的?一个程序只做一件事?并做好。程序要能协作。程序要能处理文本流?因为这是最通用的接口。Pob Pike?最伟大的 C 语言大师之一?在《Notes on CProgramming》中从另一个稍微不同的角度表述了 Unix 的哲学?原则 1?你无法断定程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方?所以另急于胡乱找个地方改代码?除非你已经证明那儿就是瓶颈所在。原则 2?估量。在你没对代码进行估量?特别是没找到最耗时的那部分之前?别去优化速度。

原则 3?花哨的算法在 n 很小时通常很慢?而 n 通常很小。花哨算法的常数复杂度很大。除非你确定 n 总是很大?否则不要用花哨算法(即使 n 很大?也优先考虑原则 2)。原则 4?花哨的算法比简单算法更容易出 bug、更难实现。尽量使用简单的算法配合简单的数据结构。原则 5?数据压倒一切。如果已经选择了正确的数据结构并且把一切组织得井井有条?正确的算法也就不言自明。编程的核心是数据结构?而不是算法。原则 6?没有原则 6。 Ken Thompson-Unix 最初版本的设计者和实现者?禅宗偈语般地对 Pike 的原则 4 作了强调?拿不准就穷举。 Unix 哲学中更多的内容不是这些先哲们口头表述出来的?而是由他们所作的一切和 Unix 本身所作出的榜样体现出来的。从整体上来说?可以概括为以下几点?1、模块原则?使用简洁的接口拼合简单的部件。2、清晰原则?清晰胜于机巧。3、组合原则?设计时考虑拼接组合。4、分离原则?策略同机制分离?接口同引擎分离。5、简洁原则?设计要简洁?复杂度能低则低。6、吝啬原则?除非确无它法?不要编写庞大的程序。7、透明性原则?设计要可见?以便审查和调试。8、健壮原则?健壮源于透明与简洁。

9、表示原则?把知识叠入数据以求逻辑质朴而健壮。10、通俗原则?接口设计避免标新立异。11、缄默原则?如果一个程序没什么好说的?就沉默。12、补救原则?出现异常时?马上退出并给出足够错误信息。13、经济原则?宁花机器一分?不花程序一秒。14、生成原则?避免手工 hack?尽量编写程序去生成程序。15、优化原则?雕琢前先要有原型?跑之前先学会走。16、多样原则?决不相信所谓"不二法门"的断言。17、扩展原则?设计着眼未来?未来总比预想来得快。 MSN 空间完美搬家到新浪博客?

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!