题外话：一个月之前，刚刚读完《unix编程艺术》这本据说有些“愤青”的书，读书的过程，感觉是种享受，不但unix本身是艺术，连作者著书也是艺术，本想就本书写篇读感，但是感觉现阶段的自己还总结不了书中的精华。昨天，在回家路上无意看见了这篇文章，感觉很好，特转载给大家。出处是http://blog.leezhong.com/reading/2010/12/21/the-art-of-unix-programming.html



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

清晰原则 (清晰胜于技巧)

组合原则 (设计时考虑拼接组合)

Unix程序员偏爱这种做法并不是因为它们仇视视图界面，而是因为如果程序不采用简单的文本输入输出流，它们就极难衔接。
把策略同机制揉成一团有两个负面影响：一来会使策略变得死板，难以适应用户需求的改变，二来也意味着任何策略的改变都可能会动摇机制。
来自多方面的压力常常会让程序变得复杂(bug更多)，其中一种压力就是来自技术上的虚荣心理。Unix程序员相互比的是谁能够做到"简洁而漂亮"并以此为荣。
"大"有两重含义：体积大，复杂程度高。程序大了，维护起来就困难。由于人们对花费了大量精力才做出来的东西难以割舍，结果导致在庞大的程序中把投资浪费的注定要失败或者并非最佳的方案上。

设计时如果充分考虑到这些要求会给整个项目全过程都带来好处。至少，调试选项的设置应该尽量不要在事后，而应该在设计之初便考虑进去。这是考虑到程序不但应该能够展示其正确性，也应该能够把原开发者解决问题的思维模型告诉后来者。

健壮原则 (健壮源于透明与简洁)

这也就带来了让程序健壮的方法，就是让程序的内部逻辑更易于理解。要做到这一点主要有两种方法：透明化和简洁化。
数据要比程序逻辑更容易驾驭。所以如果要在复杂数据和复杂代码中选择一个，宁愿选择前者。更进一步：在设计中，应该主动将代码的复杂度转移到数据中去。

缄默原则 (无话可说？那就沉默)

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

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

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

还不知道瓶颈所在就匆忙进行优化，这可能是唯一一个比乱加功能更加损害设计的错误。从畸形的代码到杂乱无章的数据布局，牺牲透明性和简洁性而片面追求速度、内存或者磁盘使用的后果随处可见。
多样原则 (绝不相信所谓"不二法门"的断言)

要为数据格式和代码留下扩展的空间，否则就会发现自己常常被原先不明智选择捆住了手脚，因为你无法既要改变它们又要维持对原来的兼容性。