“编程的核心是数据结构，而不是算法”，即使最简单的程序逻辑人类来验证也很困难，但就算复杂的数据，对人类来说也相对容易推导和建模。五十个节点的指针树要比五十行程序的流程图更清楚。

“编程的本质是控制复杂度”，而流程图、过程化、结构化、面向对象以及其它方法论恰好“成功”将复杂度提升到人脑不能处理的地步。所以，降低整体复杂度的方法是用清晰的接口把若干简单模块组合成一个复杂软件。

“简洁最美”，最错综复杂的美妙设计，常常使我们的设计能力超出排错能力，结果是代价高昂的废品。

“接口和引擎分离”，把复杂的GUI界面与后台处理分做两端，中间用简单协议架桥。

“可见才可掌控”，软件系统的透明性就是说，你能一眼看出它在干什么，要能监视到内部状态。

“撑不下去，马上退出”，出现异常，补救措施明明又没成功，还挺在那里，很久才发现是最坏的一种情况。要么“响亮的倒塌，要么为工作链下一环程序输出一个严谨干净的正确数据”。

“过早的优化是万恶之源”，先要求运行，再求正确，最后再求快。还不知道瓶颈就匆忙优化，是唯一一个比乱加功能更损害设计的错误。“最强大的优化工具是DELETE键”。

“善用工具”，教会电脑生成一些简单的代码；一旦有人解决了某个问题，就直接拿过来用，尽可能一切都自动化。

“宁花机器一分，不花程序员一秒”。有的程序员写程序是“为机器写”，过份追求效率。想方设法让机器“少做些事”，因此耽误大量时间精力。与此相对地，我们可以使用一些简单直接的，即使是相对费时的算法，浪费了一些“机器的时间”，但节省了程序员的精力。又比如，有的语言，将程序员从内存释放中解脱出来，可以更高效的开发，这也是一种珍惜程序员精力，让机器多做事的例子。
BTW：我其实一直以来都是做C＋＋的，从前总觉得这才是最“高效”的语言，一向对JAVA和脚本语言不感冒，但渐渐才明白，一把钥匙开一扇门，有时候，甚至是大多数时候，选择后者才是“高效”的做法。机器只不过是通了电一堆晶体管，让它费点力没什么。

综上所述，4个字母：KISS－－Keep It Simple, Stupid!


最后，还是把UNIX哲学的17个原则完整列一下：
1、 模块性原则：写简单的，通过干净的接口可被连接的部件。
2、 清楚原则：清楚要比小聪明好。
3、 合并原则：设计能被其它程序连接的程序。
4、 分离原则：从机制分离从策略，从实现分离出接口。
5、 简单原则：设计要简单；只有当你需要的时候，增加复杂性。
6、 节俭原则：只有当被证实是清晰，其它什么也不做的时候，才写大的程序。
7、 透明原则：为使检查和调试明显更容易而设计。
8、 健壮性原则：健壮性是透明和简单的追随者。
9、 表现原则：把知识整理成资料，于是程序逻辑能变得易理解和精力充沛的。
10、最小意外原则：在接口设计中，总是做最小意外事情。
11、沉默原则：当一个程序令人吃惊什么也不说的时候，他应该就是什么也不说。
12、修补补救：当你必须失败的时候，尽可能快的吵闹地失败。
13、经济原则：程序员的时间是宝贵的；优先机器时间节约它。
14、产生原则：避免手工堆砌；当你可能的时候，编写可以写程序的程序。
15、优化原则：在雕琢之前先有原型；在你优化它之前，先让他可以运行。
16、差异原则：怀疑所有声称的“唯一真理“。
17、可扩展原则：为将来做设计，因为它可能比你认为来的要快。