分享

KISS原则

 ymh 2005-11-21

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就做这个上的市(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原则将不断体现在新旧版本的差异中,等新版本发布后,我会写一个这段时间的经验教训来和大家讨论。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多