Unix设计哲学原则(摘自《Unix编程艺术》)

原创
2015/01/21 15:46
阅读数 881

看了《Unix编程艺术》,这个里面讲的观念对现有产品和项目的设计有很多借鉴意义,建议大家都能读读(不过中文版翻译的有点烂,看的有点纠结)。这里总结下几种原则。

Unix哲学的原则:

--模块原则:使用简洁的接口拼接简单的部件。

----“计算机编程的本质就是控制复杂度”,编制复杂软件的方法就是降低整体复杂度,用清晰的接口把若干简单的模块组合成一个复杂软件。

--清晰原则:清晰胜于机巧。

----复杂的代码容易滋生BUG,注释的重要性,代码的可维护性

--组合原则:设计时考虑拼接组合。

----软件需要能相互通信,不然就会陷入复杂度;输入输出的简单、文本化、面向流、设备无关的格式;用简单的命令流或者是应用协议串联分散的各个组件。

--分离原则:策略同机制分离,接口同引擎分离。

----GUI环境中被广泛使用,感官是策略、光栅操作和组合是机制不变;Emacs用LISP来控制,C编写编辑原语操作;通过套接字分离前后端。

--简洁原则:设计要简洁,复杂度能低就低。

----避免技术上的虚荣心,玩转复杂的概念和抽象。设计能力超出实现和排错能力,代价就是高昂的。“错综复杂的美妙事物”听起来自相矛盾,要做到“简洁而漂亮”(参考MAC的设计理念,简单就是美);商业上优秀的设计被“特性清单”扼杀。避免庞大BUG陷阱的方法就是鼓励“简洁为美”的软件文化。

--吝啬原则:除非却无他法,不要编写庞大的程序。

----“大”就是体积大,复杂度高。程序大了就难于维护。

--透明性原则:设计要可见,以便审查和调试。

----前期多做工作减少调试的工作量-设计充分考虑透明性和显见性。透明性:一眼就能看出软件是在做什么以及怎样做;显见性:程序带有监视和显示内部状态的功能。接口简洁。

--健壮原则:健壮源于透明与简洁。

----设计时考虑承受极大量的输入。异常的处理。透明和简洁。

--表示原则:把知识叠入数据以求逻辑质朴而健壮。

----数据要比编程逻辑更容易驾驭。在复杂数据和复杂代码中宁愿选择复杂的数据。设计中将代码的复杂度转移到数据中。

--通俗原则:接口设计避免标新立异。

----“最少惊奇原则”最易用的程序就是用户需要学习新东西最少的程序。关注目标受众,最终用户。

--缄默原则:如果一个程序没有什么好说的,就沉默。

----行为良好的程序应该是默默工作,绝不碍手碍脚。

--补救原则:出现异常时,马上退出并给出足够多错误信息。

----考虑最坏的情况。“宽容的收,谨慎的发”。要么响亮的倒塌,要么为工作链的下一个程序提供严禁干净的数据。

--经济原则:宁化机器一分,不花程序一秒

----典型做法就是使用更高级的语言Python、Java、Lisp等来进行开发,降低复杂度,将复杂度留给机器去处理。

--生成原则:避免手工hack,尽量编写程序去生成程序

----代码生成器解决大量重复容易出错的编码。Parser/Lexer生成器,makefile生成器,GUI构建器等。

--优化原则:雕琢前要有原型,跑之前要学会走。

----“过早优化是万恶之源”,先要有原型,不用等到100%了再去做。过早的局部优化会妨碍全局优化,整体设计要避免过早局部优化的干扰。“先制作原型,再精雕细琢。优化之前先确保能用”。“先求运行,在求正确,最后求快”。代码最强大的优化工具就是delete操作

--多样原则:决不相信所谓“不二法门”的断言。

----设计一个僵化、封闭、不愿与外界沟通的软件,简直就是一种病态的傲慢。Unix奉行广泛采用多语言、开发的可扩展系统和用户定制机制。

--扩展原则:设计着眼未来,未来总比预想来得快。

----没有所谓“不二法门”,总是在变的。要给代码留下扩展的空间。协议和文件格式要能自描述性也便进行扩展。设计代码要有很好的组织性,以便后来者能快速添加新功能,而无需拆毁整个架构。设计着眼于未来节省的就是自己的精力。

摘自:《Unix编程艺术》

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
13 收藏
0
分享
返回顶部
顶部