设计思想与编程艺术概念.docVIP

后来他这样总结道（引自《Unix的四分之一世纪》）： Unix哲学是这样的：一个程序只做一件事，并做好。程序要能协作。程序要能处理文本流，因为这是最通用的接口。 从整体上来说，可以概括为以下几点： 01.模块原则：使用简洁的接口拼合简单的部件。 02.清晰原则：清晰胜于机巧。 03.组合原则：设计时考虑拼接组合。 04.分离原则：策略同机制分离，接口同引擎分离。 05.简洁原则：设计要简洁，复杂度能低则低。 06.吝啬原则：除非确无它法，不要编写庞大的程序。 07.透明性原则：设计要可见，以便审查和调试。 08.健壮原则：健壮源于透明与简洁。 09.表示原则：把知识叠入数据以求逻辑质朴而健壮。 10.通俗原则：接口设计避免标新立异。 11.缄默原则：如果一个程序没什么好说的，就沉默。 12.补救原则：出现异常时，马上退出并给出足够错误信息。 13.经济原则：宁花机器一分，不花程序员一秒。 14.生成原则：避免手工hack，尽量编写程序去生成程序。 15.优化原则：雕琢前先要有原型，跑之前先学会走。 16.多样原则：决不相信所谓“不二法门”的断言。 17.扩展原则：设计着眼未来，未来总比预想来得快。 1.6.1? 模块原则：使用简洁的接口拼合简单的部件 正如Brian Kernighan曾经说过的：“计算机编程的本质就是控制复杂度”[Kernighan-Plauger]。排错占用了大部分的开发时间，弄出一个拿得出手的可用系统，通常与其说出自才华横溢的设计成果，还不如说是跌跌撞撞的结果。 汇编语言、编译语言、流程图、过程化编程、结构化编程、所谓的人工智能、第四代编程语言、面向对象、以及软件开发的方法论，不计其数的解决之道被抛售者吹得神乎其神。但实际上这些都用处不大，原因恰恰在于它们“成功”地将程序的复杂度提升到了人脑几乎不能处理的地步。就像Fred Brooks的一句名言[Brooks]：没有万能药。 要编制复杂软件而又不至于一败涂地的唯一方法就是降低其整体复杂度——用清晰的接口把若干简单的模块组合成一个复杂软件。如此一来，多数问题只会局限于某个局部，那么就还有希望对局部进行改进而不至牵动全身 1.6.2? 清晰原则: 清晰胜于机巧 维护如此重要而成本如此高昂；在写程序时，要想到你不是写给执行代码的计算机看的，而是给人——将来阅读维护源码的人，包括你自己——看的。 在Unix传统中，这个建议不仅意味着代码注释。良好的Unix实践同样信奉在选择 算法和实现时就应该考虑到将来的可扩展性。而为了取得程序一丁点的性能提升就大幅度增加技术的复杂性和晦涩性，这个买卖做不得——这不仅仅是因为复杂的代码容易滋生bug，也因为它会使日后的阅读和维护工作更加艰难。 相反，优雅而清晰的代码不仅不容易崩溃——而且更易于让后来的修改者立刻理解。这点非常重要，尤其是说不定若干年后回过头来修改这些代码的人可能恰恰就是你自己。 永远不要去吃力地解读一段晦涩的代码三次。第一次也许侥幸成功，但如果发现必须重新解读一遍——离第一次太久了，具体细节无从回想——那么你该注释代码了，这样第三次就相对不会那么痛苦了。 —Henry Spencer 1.6.3? 组合原则：设计时考虑拼接组合 如果程序彼此之间不能有效通信，那么软件就难免会陷入复杂度的泥淖。 在输入输出方面，Unix传统极力提倡采用简单、文本化、面向流、设备无关的格式。在经典的Unix下，多数程序都尽可能采用简单过滤器的形式，即将一个输入的简单文本流处理为一个简单的文本流输出。 抛开世俗眼光，Unix程序员偏爱这种做法并不是因为他们仇视图形用户界面，而是因为如果程序不采用简单的文本输入输出流，它们就极难衔接。 Unix中，文本流之于工具，就如同在面向对象环境中的消息之于对象。文本流界面的简洁性加强了工具的封装性。而许多精致的进程间通讯方法，比如远程过程调用，都存在牵扯过多各程序间内部状态的倾向。 要想让程序具有组合性，就要使程序彼此独立。在文本流这一端的程序应该尽可能不要考虑文本流另一端的程序。将一端的程序替换为另一个截然不同的程序，而完全不惊扰另一端应该很容易做到。 GUI可以是个好东西。有时竭尽所能也不可避免复杂的二进制数据格式。但是，在做一个GUI前，最好还是应该想想可不可以把复杂的交互程序跟干粗活的算法程序分离开，每个部分单独成为一块，然后用一个简单的命令流或者是应用协议将其组合在一起。 在构思精巧的数据传输格式前，有必要实地考察一下，是否能利用简单的文本数据格式；以一点点格式解析的代价，换得可以使用通用工具来构造或解读数据流的好处是值得的。 当程序无法自然地使用序列化、协议形式的接口时，正确的Unix设计至少是，把尽可能多的编程元素组织为一套定义良好的API。这样，至少你可以通过链接调用应用程序，或者