Unix哲学是自下而上，而不是自上而下的，注重实效，立足于丰富的经验，你不会在正规方法学和标准中找到它。
Unix管道的发明人Doug
McIlroy曾经说过：
1、让每个程序就做好一件事，如果有新任务就重新开始，不要往新程序中加入功能而搞的复杂。
2、假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序是未知的。输出中不要有无关的信息干扰，避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
3、尽可能早将设计和编译的软件投入试用，哪怕是操作系统也不例外，理想情况下应该是几星期内，对抽劣的代码别犹豫，扔掉重写。
4、优先使用工具，而非拙劣的帮助来减轻编程任务的负担，工欲善其事，必先利其器。
Rob
Pike在《Notes on C
programming》中提到：
原则1：你无法断行程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急于胡乱找个地方改代码，除非你已经证实那儿就是瓶颈所在。
原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。
原则3：花哨的算法，在n很小的适合通常很慢，而n通常很小。花哨算法的常数复杂度很大，除非你确定n一直很大,否则不要用花哨算法（即使n很大，也要优先考虑原则2）。
原则4：花哨的算法比简单的算法更容易出bug
,更难实现。尽量使用简单的算法配合简单的数据结构。
原则5：数据压倒一切。如果已经选择了正确的数据结构并且把一切组织得井井有条，正确的算法也就不言自明，编程的核心是数据结构，而不是算法。
原则6：没有原则6.
Ken
Thompson对原则4做了强调：
拿不准就穷举。
Unix哲学的17条原则：
1、模块原则：简洁的接口拼合简单的部件。
2、清晰原则：清晰胜于机巧。
3、组合原则：设计时考虑拼接组合。
4、分离原则：策略同机制分离，接口同引擎分离。
5、简洁原则：设计要简洁，复杂度能低则低。
6、吝啬原则：除非却无他法，不要编写庞大的程序。
7、透明性原则：设计要可见，以便审查和调试。
8、健壮原则：健壮源于透明与简洁。
9、表示原则：把知识叠入数据，以求逻辑质朴而健壮。
10、通俗原则：接口设计避免标新立异。
11、缄默原则：如果一个程序没什么好说的，就沉默。
12、补救原则：出现异常时，马上退出，并给出足够错误信息。
13、经济原则：宁花机器一分，不花程序员一秒。
14、生成原则：避免手工hack，尽量编写程序去生成程序。
15、优化原则：雕琢前先要有原型，跑之前先学会走。
16、多样原则：绝不相信所谓“不二法门”的断言。
17、扩展原则：设计着眼未来，未来总是比预想来得快。
Unix哲学之一言以蔽之：KISS
Keep
it simple,stupid!
应用unix哲学：
1、只要可行，一切都应该做成与来源和目标无关的过滤器。
2、数据流应尽可能的文本化（这样可以用标准工具来查看和过滤）。
3、数据库部署和应用协议应尽可能文本化（让人阅读和编辑）。
4、复杂的前端（用户界面）和后端应该泾渭分明。
5、如果可能，用c编写前，先用解释性语言搭建原型。
6、当且仅当只用一门编程语言会提高程序复杂度时，混用语言编程才比单一语言编程来得好。
7、宽收严发（对接收的东西要包容，对输出的东西要严格）
8、过滤时，不需要丢弃的消息绝不丢。
9、小就是美。在确保完成任务的基础上，程序功能尽可能的少。
最后强调的是态度：
要良好地运用unix哲学，你就应该不断地追求卓越，你必须相信，程序设计是一门技艺，值得你付出所有的智慧、创造力和激情。否则，你的视线就不会超越那些简单、老套的设计和实现；你就会在应该思考的时候急急忙忙跑去编程。你就会在该无情删繁就简的时候反而把问题复杂化——然后你还会反过来奇怪你的代码怎么会那么臃肿，那么难以调试。
要良好地运用unix哲学，你应该珍惜你的时间绝不浪费。一旦某人已经解决了某个问题，就直接拿来利用，不要让骄傲或偏见拽住你又去重做一遍。永远不要蛮干；要多用巧劲，省下力气在需要的时候用，好钢用到刀刃上。善用工具，尽可能将一切自动化。
软件设计和实现是一门充满快乐的艺术，一种高水平的游戏。如果这种态度对你来说听起来有些荒谬，或者令你隐约感到有些困窘，那么请停下来，想一想，问问自己是不是已经把什么给遗忘了。如果只是为了赚钱或者打发时间，你为什么要搞软件设计，而不是别的什么呢？你肯定曾经也认为软件设计值得你付出激情……
要良好地运用unix哲学，你需要具备（或者找回）这种态度。你需要用心。你需要去游戏。你需要乐于探索。
操作系统的风格元素：
1、什么是操作系统的统一性理念
2、多任务能力
3、协作进程（IPC）
4、内部边界
5、文件属性和记录结构
6、二进制文件格式
7、首选用户界面风格
8、目标受众
9、开发的门坎