RQ正撰

　　懒 只有懒惰的程序员才会去编写那些可以最终代替自己工作的自动化工具，才不会成天为了实现相似的功能去编写大段大段冗余重复的代码 - 这种代码往往是软件后期维护和重构的天敌。通常来说，由于惰性的驱使所产生出来的工具和程序将最终极大的提高生产开发的速度。

　　当然，对于一个程序员来说，光光具备懒惰这个要素还是不够的。在享受懒惰之前，他必须以最大的热情和最高的效率去研究解放自己的途径，比如：找到最有助于开发的工具，最能体现“一次编写，多次复用”精神的代码架构的设计。只有在这些必要的工作之后，才可能真正享受轻松编程的乐趣。

　　所以“懒”的精髓用一句老话来描述，那就是磨刀不误砍柴功。如果你不想办法磨亮手中的柴刀，就算一天二十四小时都在砍柴，效果也不如拿把锋利的斧头一天只砍一小时。

　　从这个角度来说，Google给员工的20%自由时间是完全发挥了“懒”的能动力。为了更好的享受偷懒的乐趣，员工会更加具有创造力的去高效完成自己的任务。

　　夸张一点来说，懒惰才是人类进步的原动力。

　　笨 这一点似乎比懒更让人不能接受。在解释这里所说的笨的具体含义之前，我们先看看一个聪明人（或者说认为自己足够聪明）会做什么：

1) 停止学习新的东西
2) 不愿意用批判的眼光去审视自己的工作

　　第1点将使我们很难去接受或者主动的去研究一项新的技术 - 即使新技术能带给他更多工作上的便利。第2点会使我们无法清晰的分析自身工作的问题所在，要对其进行改进或者重构就更加困难。

　　从这两点来考虑，作为一个程序员太自以为是不见得是件好事情。由于对自身的过于自信，往往无法客观的看待自己和自己的工作。相反的，笨一点（确切的说，谦逊一点）有时候倒有助于开发的顺利进行。举例来说，当程序出现bug的时候，最好尽早承认问题是出在自己编写的代码上面而不是在于编译器（当然除非是字节高低位编码方式之类的问题，这种问题编译器会是错误的根源之一）。如果你太自负的认为自己的程序没有问题而去猜测可能是编译器或者其他的什么外部因素出问题的话，那么十有八九你会在调试过程中走上一长段的弯路。

　　程序员应该笨一些的更为关键的原因在于，当需要思考问题的最佳解决方案的时候，往往要求我们首先要跳出思维定式。你对系统了解的越多，积累了越多的经验，就越难走出已有的局限，可以尝试的范围就越小。相反的，对于一个什么也不懂的门外汉来说，因为没有任何失败的记忆和潜规则的约束，也就没有什么是“不可能”的，这样的大脑所能迸发出来的在专业人士看起来愚不可及的想法往往正是解决问题所需要的关键点所在。

　　可能很多程序员都会有类似的经历，在面对别人（尤其是其他部门）对于一个bug的描述的时候，必须把自己摆在一个普通用户而不是程序开发者的角度来分析问题，否则的话可能你永远都想象不到这种错误也会发生。越能让自己变得“笨”起来，越能很快的定位到问题所在。我们先看看这么一段关于web开发问题的程序员和客服人员的对话：

“从昨天开始我们的用户就看不到我们站点上的Logo了。”
“他试过重启浏览器么？”
“是的。”
“他试过重启电脑么？”
“是的。”
“他清空过浏览器Cache么？”
“是的。”
“他的浏览器版本是IE6么？”
“是的。”
“他确信是真的看不到Logo了么？”
“是的。”
“他是在电脑显示器屏幕上看我们的站点么？”
“什么？”
“比如说，它可能是打印出来看不到？”
“不。他是在显示器上看的。”
“除了站点Logo之外，他是不是其他的图片都看不到？”
“什么？哦。我再问问他。”

　　从这段对话来说，估计用户实际上是禁止了浏览器显示图片的功能（或者他儿子干的）。不管怎么样，如果你不是用这种傻瓜式的思维方式去寻找答案的话，可能怎么也找不到问题的根源。

　　很多时候，问题发现者对于问题的描述往往是非常片面的，并且加上了主观推测的成分在里面。如果你不能透过这些主观的描述去发现问题的实际表象，或者说根本就是你自己根据程序员的经验逻辑来判断问题所在的话，十有八九会在歧途上越走越远。

　　对于白痴级的问题，只有用白痴的行为方式才能得到答案。

　　即便同样是程序员，但对于你的程序并不熟悉，也会经常有这样的疑问：“为什么我调用你的代码出错了？”这种问题的答案，很多时候是因为他们的调用方式不对，或者调用了错误的库文件，或者库文件的版本使用不当，或者根本就没有联接到库文件上。当你想让同事帮你检查一下程序中的一个莫名其妙的bug的时候，一般来说希望他对你的系统了解的越少越好，只有这样他才会问一些你自己认为绝对不可能出问题的“笨”问题。

　　所以“笨”的精髓在于你如何去思考问题：不要假设些什么，把自己假设的太完美或者把别人假设的很聪明都会使你忽视一些很浅显的事实。思考的前提必须是完整的事实表象，思考的过程必须是抛弃成见的问题跟踪。在发现事实之前作太多的主观思考和臆断，倒不如把自己当作白痴一样来行动更好。

　　当然，不思考的一个极端是不分情况都直接去做，另一个极端是完全脱离事实，用思想办事。一个优秀的程序员应该做好权衡。10次决定里面的1次错误决定不是致命的；只做5次正确的决定而另外5次没有任何决定才更糟糕。

　　最后是一个蜈蚣的故事。蜈蚣本来用自己的几百只脚走路走的很快很好，但他从来没有花时间去想过为什么。直到有一天，一只臭虫问他：“你是怎么管理好你的几百只脚的？你不觉得这是件很困难的事情吗？”臭虫问完之后就走了。只剩下蜈蚣坐在地上，不停的思考这个问题，却一直想不出个究竟。从此以后，这只蜈蚣再也没办法好好的走路了。

再转另一篇经典文章

原文出处：http://www2.uuzone.com/blog/mao/35238.htm

KISS原则

KISS? 此KISS不是彼KISS, 乃Keep It Simple, Stupid! 直接翻译过来，就是“保持简单，傻瓜！”（ Stupid这个词，在英语中含义也很复杂，很难简单翻译，这个KISS中的Stupid我认为更多是语气词。关于这个词，最喜欢的解释是阿甘的妈妈教育的那个：“Stupid is as stupid does”.）

KISS原则可以用在很多方面，程序设计风格可以KISS, 家庭装修可以KISS, 美术设计可以KISS, 界面设计当然要KISS, ... 当然情人之间怎么能没有KISS. 曾经和我工作过的无论程序员、美工、广告人恐怕没人没听我不断说KISS,KISS,KISS...

通俗些说就是“简单就是美”。 几年前曾经看过一本“简单生活就是幸福”，说的是KISS在人生观，生活方式上的作用。 不幸的是,过去的UUZONE不够KISS,所以被称人为10吨石头； 而幸运的是，我正在和uuzone的一群优秀的同学们一起苦练“炼金术”，这个“炼金术”的魔咒就是"KISS".

最近忙于点石成金的工作，而且又戒了keso,感觉几乎和IT界有些绝缘了。没想到BIDU就此上市而且市值几乎达到SINA + SNDA, 可喜可贺，无论如何BIDU是比较有技术含量的公司，最近NTES也股价飞涨，这些都说明了知识的价值在逐渐提升中。 BIDU的老师是Google, Google基本是一个典型KISS风格的公司，从其网站设计到其公司环境，无不在KISS中透露中智慧和优雅。

健硕的文章管理上的时空错乱就说到这个客户服务的故事：

微软在上海的全球技术中心同时服务微软美洲和欧洲的客户。为了保证所有工程师写出的英文的邮件不会有太多的语法和使用习惯错误，技术中心建立了“英文润色”团队，全是由英文是母语的人员组成，来帮助工程师修改发出的每一封电子邮件。任何人如果对一份英文的邮件不是很有信心的时候，发信到一个email地址（Distribution List），就可以保证在30分钟以内，得到修改的结果和避免此类错误的建议。每次回复的可能不是同一个人。

并且健硕提问：如果你来设计这个系统，会怎么做呢？ 这是一个典型的email queue的排队系统， Kana(www.kana.com)等公司已经有成熟的商业产品，Kana就做这个上的市（Nasdaq:KANA）. 然而MS却没有采用这些排队软件或者Work flow automation之类的东西，而是采用了一个简单的规则，省去了IT系统的成本，省去了沟通需求，以及维护的成本。一个简单的规则就“运行到现在5年了，它就那样简单而可靠的运行着”：

根本没有任何的IT系统，所有人用的是同一个email账户加上一个规则。规则是这样的：所有的人同时收到所有要阅读的信，从上班开始每5分钟为一个时间段，分配不同的人来值班。比如，9点到9点05是Tom，9点05到9点10分是Jack，依此类推。。。每个人只处理自己邮箱里落入这个5分钟的时间段的信件，其他的都忽略。接到以后，后面的25分钟里面回复前5分钟的信。25分钟之后，进入下一个自己收信的5分钟。理论上，6个人一班，每半个小时一个轮回。而5分钟里面的信件，每个人自己安排，保证在下一个5分钟到来前的25分钟内回复完毕就好了。

那篇文章里健硕还举了类似的其他例子，大家可以自己去看。

从Microsoft相关学到的，是Microsoft press出的那本经典的"Coding Complete"中讲的一个故事：

Microsoft附近有一个咖啡馆，是那种可以不断续杯海饮的那种，他们提供两种不同的咖啡豆煮的咖啡，但价格相同，杯子的分量也相同。 这本书的作者发现一个令人惊奇的事实：就是这家咖啡馆的女招待都有着不可思议的好记性 -- 每当客人要续杯的时候，她们从来不需要问客人曾经选择的咖啡种类，却绝对不会把客人选择的咖啡种类搞错！ 而且每个人都是如此！！

秘密原来不是这些女招待记忆超群，也不是她们受过特殊培训，更不是咖啡杯上有RFID之类的装置！ 而是在于装咖啡的马克杯图案颜色的区别！ 女招待上班第一天就被告知，咖啡杯的图案是红色的，是A coffee; 图案是蓝色的B Coffee. 简单吧！ 一个简单有效的规则比什么都有效！这就是KISS原则的神奇威力。

好久不写blog, 不妨自恋一下，回忆下我第一次的KISS经历， 至今记忆犹新. 那是大学二年级的故事，一个阳光明媚的早晨，没有课，也没有活动... 在学校老图书馆前的一个石凳上, 我终于鼓起勇气...(以下删2000字, 请翻页...)






























































...（不要激动）...我终于鼓起勇气，决定开始钻研枯燥难啃的386汇编语言和当时很有技巧和挑战的TSR(Terminate Stay Resident)开发，所以拿出刚刚从图书馆借到的一本老外写的书（书名忘了，大致是80386汇编语言技巧之类的）， 书的前言很精彩，大致说80386汇编其实也没有什么可怕，保护模式编程其实一样很有趣云云，其中作者反复提了一个他 “收益匪浅”的原则--KISS, 并且解释了Keep It Simple, Stupid的含义，以及在写汇编代码的时候如何KISS的方法。

此前我对KISS闻所未闻，而且最崇尚的就是各种花里胡哨的“编程技巧”，现在却看到一本讲最让人晕头转向的80386保护模式下的汇编语言的书的作者在说，要keep it simple, 而且后面还有个"stupid"（当时的英语水平，我真的不理解，还以为也要keep stupid呢）。

果然这本书给我留下的最大收获就是开始接受了这个"KISS"， 而且真的是收益匪浅。前些天看到XDoclet in action一书的作者在他的一篇blog中用了"Perl Programming"作者Larry Wall的一句名言：

“We will encourage you to develop the three great virtues of a programmer: laziness, impatience and hubris.”

好的程序员要有3个宝贵品德：懒惰、没耐心和骄傲， 某种程度上我非常赞同。这个观点可以专门写个长篇大论，这里就不跑题展开了，稍微说一下：

• 懒惰： KISS, 讨厌复杂的； 宁可加班加点、承担风险也要寻求“偷懒”的捷径；
  
• 没耐心：讨厌重复劳动，不重复自己(DRY原则: Don't Repeat Yourself); KISS, 没耐心搞“复杂繁琐”的东西；
  
• 骄傲: 相信自己能写出一流的软件，相信自己可以做出最棒的设计；坚决相信KISS可以一直到天荒地老；

说回到UUZone的改版，KISS原则将不断体现在新旧版本的差异中，等新版本发布后，我会写一个这段时间的经验教训来和大家讨论。