Unix编程艺术 读书笔记

Unix管道的发明人、Unix传统的奠基人之一Doug Mcllroy在[Mcllroy78]中曾经说过:

  • (i)让每个程序就做好一件事。如果有新任务,就重新开始,不要往原程序中加入新功能而搞得复杂。
  • (ii)假定每个程序的输出都会成为另一个程序的输入,哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏式和二进制格式输入。不要坚持使用交互式输入。
  • (iii)经可能早地将设计和编译的软件投入试用,哪怕是操作系统也不例外,理想情况下,应该是在几星期内。对拙劣的代码别犹豫,扔掉重写。
  • (iv)优先使用工具而不是拙劣的帮助来减轻编程任务的负担。工欲善其事,必先利其器。

后来他这样总结道(引自《Unix的四分之一世纪》):

Unix哲学是这样的:一个程序制作一件事,并做好。程序要能协作。程序要能处理文本流,因为这是最通用的接口。

Rob Pike,最伟大的C语言大师之一,在《Notes on C Programming》 中从另一个稍微不同的角度阐述了Unix的哲学[Pike]:

  • 原则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.扩展原则:设计着眼未来,未来总比预想来得快。

正如Brian Kernighan曾经说过的:“计算机编程的本质就是控制复杂度”

汇编语言、编译语言、流程图、过程化编程、结构化编程、所谓的人工智能、第四代编程语言、面向对象、以及软件开发的方法论,不计其数的解决之道被抛售者吹得神乎其神。但实际上这些用处都不大,原因恰恰在于它们“成功”地将程序的复杂度提升到了人脑几乎不能处理的地步。就像Fredbrooks的一句名言[Brooks]:没有万能药

永远不要去吃力地解读一段晦涩的代码三次。第一次也许侥幸成功,但如果发现必须重新解读一遍--离第一次太久了、具体细节无从回想--那么你该注释代码了,这样第三次就相对不会那么痛苦了。
--Henry Spencer

“错综复杂的美妙事务”听来自相矛盾。Unix程序员相互比的是谁能够做到“简洁而漂亮”并以此为荣,这一点虽然只是隐含在这些规则之中,但还是很值得公开提出来强调一下。
--Doug Mcllroy

最小立异原则的另一面是避免表象相似而实际略有不同。这回极端危险,因为表象相似往往导致人们产生错误的假定。所以最好不要让不同事务有明显区别,而不要看起来几乎一模一样。
--Henry Spencer

由于略微不同的一些原因,Donald Knuth(程序设计领域中屈指可数的经典著作之一《计算机程序设计艺术》的作者)广为传播普及了这样的观点:“过早优化是万恶之源”。他是对的。
完整的句子是这样的:“97%的时间里,我们不应该考虑蝇头小利的效率提升:过早优化是万恶之源”。Knuth自称这一观点来自C.A.R.Hoare。

在Unix世界里,有一个非常明确的悠久传统(例证之一是Rob Pike以上的评论,另一个是Ken Thompson关于穷举法的格言):先制作原型,再精雕细琢。优化之前先确保能用。或者:先能走,再学跑。“极限编程”宗师Kent Beck从另一种不同的文化将这一点有效地扩展为:先求运行,再求正确,最后求快

我最有成效的一天就是扔掉了1000行代码。 --Ken Thompson

所有的Unix哲学浓缩为一条铁律,那就是各地编程大师们奉为圭臬的“KISS”原则:

K.I.S.S.

Keep It Simple,Stupid!

  • 只要可行,一切都应该做成与来源和目标无关的过滤器。
  • 数据流应尽可能文本化(这样可以使用标准工具来查看和过滤)。
  • 数据库部署和应用协议应尽可能文本化(让人可以阅读和编辑)。
  • 复杂的前端(用户界面)和后端应该泾渭分明。
  • 如果可能,用C编写前,先用解释性语言搭建原型。
  • 当且仅当只用一门语言编程会提高程序复杂度时,混用语言编程才比单一语言编程来得好。
  • 宽收严发(对接收的东西要包容,对输出的东西要严格)。
  • 过滤时,不需要丢弃的信息决不丢。
  • 小就是美。在确保完成任务的基础上,程序功能尽可能少。
坚持原创技术分享,您的支持将鼓励我继续创作!