摘抄自《unix编程艺术》的一些句子

模块原则：使用简洁的接口拼合简单的部件

排错战胜了大部分时间的开发时间，开出一个拿得出手的可用系统，通常与其说出版才华横溢的设计成果，还不如说是跌跌撞撞的结果。

要编制复杂软件而又不至于一败涂地的唯一方法就是降低其整体复杂度——用清晰的接口反若干简单的模块组合成一个复杂软件。如此一来，多数问题只会局限于某个局部，那么就还有希望对局部进行改进而不至于牵动全身。

 

清晰原则：清晰胜于机巧

永远不要去吃力地解读一段晦涩的代码三次。

 

分离原则：策略同机制离，接口同引擎分离

“机制，而不是策略。”GUI工具包的观感时尚来去匆匆，而油印机操作和组合去是永恒的。

实现这种剥离的一种方法是，比如，将应用按照一个库来编写，这个库包含许多由内嵌脚本语言驱动的C服务程序，而至于整个应用的控制流程则用脚本来撰写而不是用C语言。另一个方法是将应用程序分成可以协作的前端和后端进程，通过套接字层的专用应用协议进行通讯。前端实现策略，后端实现机制。

 

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

“错综复杂的美妙事物”听来自相矛盾。

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

 

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

即使最简单的程序逻辑让人类来验证也很困难，但是就算是很复杂的数据，对人类来说，还是相对容易地就能推才建模的。不信可以试试比较一下，是五十个节点的指针树，还是五十行代码的流程图更清楚或者，比较一下空间用一个数组初始化器来表示转换表，还是用switch语句更清楚呢？

数据要比编程更容易驾驭。所以接下来，如果要在复杂数据和复杂代码中选择一个，宁愿选择前者。更进一步：在设计 中，你应该主动将代码的复杂度转移到数据之中去。

 

缄默原则：如果一个程序没什么好说的，就保持沉默

设计良好的程序将用户的注意力视为有限的宝贵资源。

 

补救原则：出现异常时，马上退出并给出足量错误信息

软件要尽可能从容地就会各种错误输入和自身的运行错误。

“宽容地收，谨慎地发”。就算输入的数据很不规范，一个设计良好的程序也会尽量领会其中的意义，以尽量与别的程序协作；然后，要么响亮地倒塌，要么为工作链下一环的程序输出一个严谨干净正确的数据。

 

经济原则：宁花机器一分，不花程序员一秒

那些需要对核爆炸进行建模或处理三维电影动画的除外。

生成原则：避免手工hack，尽量编写程序去生成程序

 

优化原则：雕琢前先得有原型，跑之前先学会走

90%的功能现在能实现，比100%的功能永远实现不了强。

先制作原型，再精雕细琢。优化之前先确保能用。

借助原型化找出哪些功能不必实现，有助于对性能进行优化；那些不用写的代码显然无需优化。目前，最强大的优化工具恐怕就是delete键了。

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

K.I.S.S

 

Unix至少设立了三层内部边界来防范恶意用户或有缺陷的程序。一层是内在管理：Unix用硬件自身的内存管理单元（MMU）来保证各自的进程不会侵入到其它进程的内存地址空间。第二层是为多用户设置的真正权限组——普通用户（非root用户）的进程未经允许，就不能更改或者读取其他用户的文件。第三层是把涉及关键安全性的功能限制在尽可能小的可信代码块上。在Unix中，即使是shell（系统命令解释器）也不是什么特权程序。

 

模块性：保持清晰，保持简洁

模块化代码的首要物质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其它模块的实现码，也不会胡乱共享全局数据。模块之间通过应用程序接口（API）——一组严密、定义良好的程序调用和数据结构来通信。这就是模块化原则的内容。

有一种很好的方式来验证API是否设计良好：如果试着用纯人类语言描述设计（不许摘录任何源代码），能否把事情说清楚？养成在编码前为API编写一段非正式书面描述的习惯，是一个非常好的办法。实际上，一些是有能力的开发者，一开始总是定义接口，然后编写简要注释，对其进行描述，最后才缩写代码——因为编写注释的过程就阐明了代码必须达到的目的。

人类短期记忆能够容纳的不连续信息数就是七，加二或减二。这给了我们一个评测API紧凑性的很好的经验法则：编程者需要记忆的条目数大于七吗？如果大于七，则这个API不太可能算是严格紧凑的。

C++是反紧凑性的——该语言的设计者已经承认，他根本不指望有哪个程序员能够完全理解C++。

下次性是有助于使复杂设计也能紧凑的最重要特性之一。在纯粹的正交设计中，任何操作均无副作用；每一个动作（无论是API调用、宏调用还是语言运算）只改变一件事，不会影响其它。无论你控制的是什么系统，改变每个属性的方法有且只有一个。

要提高设计的紧凑性，有一个精妙但强大的方法，就是围绕“解决一个定义明确的问题”的强核心算法组织设计，避免臆断和捏造。

尽量不去想一种语言或操作系统最多能做多少事情，而是尽量去想这种语言或操作系统最少能做到的事情。

自顶向下的设计者通常先考虑程序的主循环，以后才插入具体的事件。自底向上的设计者通常先考虑封装具体的任务，以后再按某种相关次序把这些粘合在一起。

 

为了便于数据的传输和存储，像鍡这样的数据结构，其可遍历的准空间部署需要平整化或序列化成字节流表达，以便日后能众这个表达中恢复结构。序列化（保存）操作有时也称为列集（marshaling），其反向操作（载入）称为散集（unmarshaling）。

 

许多著名的系统守护程序都接受SIGHUB作为重新初始化的信号。SIGTERM（“终止”）常常扮演温和的关闭信号。SIGTERM的行为通常包括清除临时文件和强制把最新更新刷回数据库以及其它一些类似行为。

 

要优雅地使用套接字，在Unix的传统中，首先得设计 这些套接字之间使用的应用协议——即一套请求和响应，能够简洁地表达程序通讯的主义。

由于所有这些对等进程间的IPC技法在某种程度上都很像，所以我们应该主要评估它们引起的程序复杂度开销，以及给设计造成的不透明度。