Unix 哲学是在 Unix 先哲们和 Unix 本身所作出的榜样中体现出来的。可以概括为以下原则：
用清晰的接口把若干简单的模块组合成一个复杂软件。
这样，多数问题就只会局限在某个局部，那么就还有希望对局部进行优化改进而不至于牵动全身。
复杂的代码更容易滋生bug，也会使日后的阅读和维护工作更加艰难；
相反，优雅而清晰的代码不仅不容易出错，而且易于后来的修改者立刻理解。
这点很重要，因为说不定若干年后回过头来修改这些代码的人可能恰恰是你自己。
当程序无法自然地使用序列化、协议形式的接口时，正确的 Unix 设计至少是，把尽可能多的编程元素组织为一套定义良好的 API。这样，至少可以通过链接调用应用程序，或者可以根据不同任务的需求粘合使用不同的接口。
策略和机制是按照不同的时间尺度变化的，策略的变化要远远快于机制。
将策略同机制揉成一团有两个负面影响：一来会使策略变得死板，难以适应用户需求的改变，二来也意味着任何策略的改变都极有可能动摇机制。
程序的复杂性会使代价变得更高、bug更多。
要避免程序的复杂性，唯一的方法就是鼓励另一种软件文化，以简洁为美。
“大”体现在两个方面：体积大、复杂程度高。
程序越大，越难以维护。
透明性是指能够很容易的看出软件是在做什么以及怎么做的。
软件的健壮性指软件不仅能在正常情况下运行良好，而且在超出设计者设想的意外条件下也能够运行良好。
让程序健壮的方法：让程序的内部逻辑更易于理解。
而要做到上面这一点，主要有两个方法：透明性和简洁性。
程序越简洁，越透明，也就越健壮。
数据要比程序逻辑更容易驾驭。如果要在复杂数据和复杂代码中选择一个，宁愿选择前者。
更进一步：在设计中，你应该主动将代码的复杂度转移到数据之中去。
最易用的程序就是用户需要学习新东西最少的程序。
设计接口的时候，尽量按照用户最可能熟悉的同样功能接口和相似应用程序来进行建模。
行为良好的程序应该默默工作，决不唠唠叨叨，碍手碍脚。
设计良好的程序将用户的注意力视为有限的宝贵资源，只有在必要时才要求使用。
如果软件不能尽可能从容地应付各种错误输入和自身的运行错误，那就让程序尽可能以一种容易诊断错误的方式终止。
程序员的时间比机器的时间更贵。
人类很不善于干辛苦的细节工作，因此，程序中的任何手工hacking 都是滋生错误和延误的温床。
由程序生成代码几乎总是比手写代码廉价并且更值得信赖。
我们应该大量使用代码生成器使易于出错的细节自动化。
先制作原型，在精雕细琢。优化之前先确保能用。
或者：先能走，再学跑。
先求运行，再求正确，最后求快。
过早优化是万恶之源。
> 即使最出色的软件也常常会受限于设计者的想象力。
> Unix 奉行的是广泛采用多种语言、开发的可扩展系统和用户定制机制。
设计代码时，要有很好的组织，让将来的开发者增加新功能时无需拆毁或重建整个架构。
在编写代码时要考虑到将来的需要，使以后增加功能比较容易。
程序接合部要灵活，在代码中加入“如果你需要…“的注释，有义务给之后使用和维护自己编写的代码的人做点好事。
也许将来就是你自己来维护代码，而你很可能遗忘曾经写代码时的思路，所以，设计为将来着眼，节省的有可能就是自己的精力。
以上内容参考自《Unix 编程艺术》一书。