先讲两个很老的小故事。
第一个故事。
有一家日本最大的化妆品公司，收到了用户的投诉。用户抱怨买来的肥皂盒是空的。这家公司为了防止再发生这样的事故，很辛苦地发明了一台X光检查器，能够透视每一个出货的肥皂盒。
同样的事故，发生在一家小公司。他们的解决方法是买一台强力的工业电扇，对着肥皂盒猛吹，被吹走的就是空肥皂盒。
第二个故事。
美国太空总署（NASA）发现在太空失重状态下，航天员无法用墨水笔写字。于是，他们花了大量经费，研发出了一种可以在失重状态下写字的太空笔。猜猜看，俄国人是怎么解决的？（答案在本文结尾处。）
=====================
这几天，我在看Unix，发现很多人在谈"Unix哲学"，也就是开发Unix系统的指导思想。
Wikipedia上列出了好几个版本，不同的人有不同的总结。发明管道命令的Doug McIlroy总结了三条，而Eric S. Raymond则在The Art of Unix Programming一书中，一口气总结了17条（英文版，中文版）。
但是我发现，所有人都同意，"简单原则"----尽量用简单的方法解决问题----是"Unix哲学"的根本原则。这也就是著名的KISS（keep it simple, stupid），意思是"保持简单和笨拙"。
下面就是我对"简单原则"的笔记。如果你想最简单地完成一项编程任务，我认为可以从四个方面入手：
1. 清晰原则。
代码要写得尽量清晰，避免晦涩难懂。清晰的代码不容易崩溃，而且容易理解和维护。重视注释。不为了性能的一丁点提升，而大幅增加技术的复杂性，因为复杂的技术会使得日后的阅读和维护更加艰难。
2. 模块原则。
每个程序只做一件事，不要试图在单个程序中完成多个任务。在程序的内部，面向用户的界面（前端）应该与运算机制（后端）分离，因为前端的变化往往快于后端。
3. 组合原则。
不同的程序之间通过接口相连。接口之间用文本格式进行通信，因为文本格式是最容易处理、最通用的格式。这就意味着尽量不要使用二进制数据进行通信，不要把二进制内容作为输出和输入。
4. 优化原则。
在功能实现之前，不要考虑对它优化。最重要的是让一切先能够运行，其次才是效率。"先求运行，再求正确，最后求快。"（Make it run, then make it right, then make it fast.）90%的功能现在能实现，比100%的功能永远实现不了强。先做出原型，然后找出哪些功能不必实现，那些不用写的代码显然无需优化。目前，最强大的优化工具恐怕是Delete键。
==================
答案是，俄国人用铅笔。
阮兄，你火星了。
這兩個故事都已被證明是編的有窮多年了
哈哈哈，大家还是看UNIX部分吧，不过我很惊喜，有发现一个
伪科来
关于两个小故事就不说了，多Google几下就知道了。
关于编程的原则，实际上考虑下背后的原因，只有一条：成本。
由于代码大部分的时间是在被读，简单容易被理解，所以这是最好的减少成本的手段。
KISS的全称有很多不同的写法，Keep it simple and short是很常见的一种，意义上也最完整。
而keep it simple，stupid是一个比较戏虐的说法了。你看，并不是keep it simple and stupid，所以，阮一峰的翻译并不对。
另外，这几乎是现代所有软件设计的principle，并非UNIX所独有。不过什么是simple and short，显然微软，苹果,UNIX各有不同的理解，这主要还是由于各自营造的生态系统不同。
先求运行，再求正确，最后求快。”（Make it run, then make it right, then make it fast.）
这也就是敏捷先驱Kent Beck的TDD（测试驱动开发）中提到的节奏。更好术语化一点就是：不可运行->可运行->重构。
下面是我对Unix Phiosophy的看法。和博主讨论一下。我的观点基本上是相反的。 我认为Unix并不指导用户怎么去解决问题，这不是OS应该关注的。 如果OS希望指导用户怎么去解决问题，是对用户的不尊重--一如Windows。Windows的逻辑是"我发明一个功能，你看多好啊，（感激我吧！），来让我教教你怎么用，先点这个，再点那个，找出这个菜单，点出那个对话框，找到Tab，选项的意思是。。。 看看，我们的新功能给你带来了多大的好处啊。。。（比如你点击20次后终于可以把垃圾箱从桌面上去掉了）“这是WIndows的逻辑：发明功能，教育用户.
The.UNIX.Philosophy一书对Unix哲学有一些总结，最根本的一条是”small is beautiful". 其实这后边的思路是“free the user",给用户自由。我认为包括方法论上面的自由。
博主讲的其实另一方面，不是UNix的哲学，而是Unix实现的哲学。当然对于在UNIX上开发的程序员来说，最好也遵循UNIX开发中带来的哲学，但不绝对。更多的恐怕是博主自己的倾向.
Unix 是站在研发者的角度实现的系统，从使用者角度上手还是复杂了些。
必须彻底认识这种强盗式思维/论证方式的弊病。
这种思维比较认同。这犹如是读者改头换面的思维方式。
引用yabo的发言：
关于编程的原则，实际上考虑下背后的原因，只有一条：成本。 由于代码大部分的时间是在被读，简单容易被理解，所以这是最好的减少成本的手段。
代码大部分的时间是在被读,先不说开不开源,就现在程序员和用户差异愈来愈大,难道你指望用户打来投诉电话的时候告诉他去看源代码.
引用daryl的发言：
…… 如果OS希望指导用户怎么去解决问题，是对用户的不尊重--一如Windows。 …… 这是WIndows的逻辑：发明功能，教育用户. 不认同。
OS控制硬件是本分，能指导引导用户尽快上手、体验友好是进步。
商场餐馆里的服务生与导购的热情服务，体现的是对客户的尊重。 倒是很多部门和单位的公务员大爷们，冷冰冰的爱答不理，体现了对纳税人的不尊重。
---故而，普通用户早就把命令行抛弃了，迷恋命令行的思维只适合为技术人员服务，对普通用户来说，开句玩笑：用户就是爷，爷用OS是为爷服务的，不是爷为OS服务的，爷不舒服，就不买单。
ps: windows server2008时就已经有命令行shell安装方式了：“Windows Server 2008 Core”
个人觉得博主最后说的4条是没有问题的，实际上现在已经不再那么重视细节上的技巧带来的效率了，相对的是，可读性的地位越来越高，原因主要是两方面：
1 硬件性能和编译器优化技术的提高，甚至有的情况下现在写“简单”代码编译器更容易优化。
2 软件工程越来越大，牺牲可读性带来的效率提升给工程带来的负面风险和隐性成本过大。
面向对象理论、Java/C#等中间代码的提出和实现，本身就是以牺牲性能来提升模块化和可读性的例子。
KISS在wikipedia上的解释比较靠谱，不应该是简单和笨拙，简单肯定是对的，但是为什么要笨拙？
http://en.wikipedia.org/wiki/KISS_principle
Keep it simple,stupid！前面一个simple是指it，也就是做的事情，后面一个stupid，大概是骂不能保持事情简单的人是笨蛋吧，哈哈
我想说明一下，keep it short & simple 并非要求少写代码，而是要求你的代码简单易懂。
比如，这三种写法，哪种是 KISS 呢？
1) if (a>b) return true; else return false;
2) return a>b? true: false;
3) return a>b;
可读性和性能并不冲突.
翻阅无数经典C code 你会发现 这并不相悖的.
只是一般的程序员很难做到.至少在中国能把注
释写到代码里就算不错的了.
不幸的是，文中举得两个例子都是假的。
现实世界实际上需要越来越复杂的技术来支撑。
我过去时KISS的疯狂信奉者，现在已经不是了。
实际上“必要的”复杂，远比简单更适合这个世界。
引用yucca的发言：
代码大部分的时间是在被读,先不说开不开源,就现在程序员和用户差异愈来愈大,难道你指望用户打来投诉电话的时候告诉他去看源代码.
设想"MS Word",启动时间比如说用10秒，即使你连续10000秒（大约不到3小时）使用它处理文档，但程序99.9％的时间是在等待你的命令，最终程序只运行了20秒。
MS从八十年代至今用了20年左右的时间开发"MS Office" 我估计每年至少投入200人以上，每年干200天，每天干6小时 20＊200＊200＊6＊3600＝17280000000秒
雪人说 “OS控制硬件是本分，能指导引导用户尽快上手、体验友好是进步”
不同意
设想TCP/IP协议棧合四为一，上至远程文件传送方式，下至连线端口电气特性，如今有几个人还敢进行网络编程。
我认为OS的设计目标类似于硬件“稳定、高效”，OS只需要考虑程序员友好，不要今天"win16",明天"win32",后天".net",否则用户友好就是无源之水、无本之木。
单纯比较Linux、windows没啥可比性。Linux、windows也均有针对不同用户的版本。
关于编程的原则也基本认可。曾经看过一个不错的网站，年利润在千万以上，很多页面是用dw的模板功能实现的。整个网站的功能也非常简单。我觉得需求分析和实现的步骤战略也非常重要，和一峰说的第四条原则有类似之处。