Unix基本哲学

而言之，这条准则告诉我们应该设法将接口和引擎剥离开来。

    实现这种剥离的一个方法是，比如，将应用按照一个库来编写，这个库包含许多由内嵌脚本语言驱动的C服务程序，而至于整个应用的控制流程则用脚本来撰

    写而不是用C语言。这种模式的经典例子就是Emacs编辑器，它使用内嵌的脚本语言Lisp解释器来控制用C编写的编辑原语操作。我们会在第11章讨论这

    种设计风格。

    另一个方法是将应用程序分成可以协作的前端和后端进程，通过套接字上层的专用应用协议进行通讯；我们会在第5章和第7章讨论这种设计。前端实现策略，后端实现

    机制。比起仅用单个进程的整体实现方式来说，这种双端设计方式大大降低了整体复杂度，bug有望减少，从而降低程序的寿命周期成本。

    1.6.5 简洁原则：设计要简洁，复杂度能低则低

    来自多方面的压力常常会让程序变得复杂（由此代价更高，bug更多），其中一种压力就是来自技术上的虚荣心理。程序员们都很聪明，常常以能玩转复杂

    东西和耍弄抽象概念的能力为傲，这一点也无可厚非。但正因如此，他们常常会与同行们比试，看看谁能够鼓捣出最错综复杂的美妙事物。正如我们经常所见，他们

    的设计能力大大超出他们的实现和排错能力，结果便是代价高昂的废品。

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

    —Doug McIlroy

    更为常见的是(至少在商业软件领域里)，过度的复杂性往往来自于项目的要求，而这些要求常常基于当月的推销热点，而不是基于顾客的需求和软件实际能

    够提供的功能。许多优秀的设计被市场推销所需要的大堆大堆“特性清单”扼杀——实际上，这些特性功能几乎从未用过。然后，恶性循环开始了：比别人花哨的方

    法就是把自己变得更花哨。很快，庞大臃肿变成了业界标准，每个人都在使用臃肿不堪、bug极多的软件，连软件开发人员也不敢敝帚自珍。

    无论以上哪种方式，最后每个人都是失败者。

    要避免这些陷阱，唯一的方法就是鼓励另一种软件文化，以简洁为美，人人对庞大复杂的东西群起而攻之——这是一个非常看重简单解决方案的工程传统，总是设法将程序系统分解为几个能够协作的小部分，并本能地抵制任何用过多噱头来粉饰程序的企图。

    这就有点Unix文化的意味了。

    1.6.6 吝啬原则: 除非确无它法，不要编写庞大的程序

    “大”有两重含义：体积大，复杂程度高。程序大了，维护起来就困难。由于人们对花费了大量精力才做出来的东西难以割舍，结果导致在庞大的程序中把投资浪费在注定要失败或者并非最佳的方案上。

    （我们会在第13章就软件的最佳大小进行更多的详细讨论。）

    1.6.7 透明性原则：设计要可见，以便审查和调试

    因为调试通常会占用四分之三甚至更多的开发时间，所以一开始就多做点工作以减少日后调试的工作量会很划算。一个特别有效的减少调试工作量的方法就是设计时充分考虑透明性和显见性。

    软件系统的透明性是指你一眼就能够看出软件是在做什么以及怎样做的。显见性指程序带有监视和显示内部状态的功能，这