概述

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”.

敏捷开发

Google基本是一个典型KISS风格的公司，从其网站设计到其公司环境，无不在KISS中透露中智慧和优雅。

简单设计是敏捷开发中非常重要的一项实践，但是这条原则说起来简单却做起来难。因为每个程序员其实都是一个有完美主义的艺术家，所做软件其实都是一件自己的艺术品，同时受到许多关于设计方面的资料的影响，所以在做设计的时候会情不自禁的加上许多“优雅特性”和“灵活性”。

另一个很重要的原因在于，在产品推出后又不得不疲于应付客户频繁提出的许多新增加的需求的时候，会自然而然的想到：当时要是在做软件的时候能考虑到这些需求该多好啊，现在来改实在是太麻烦了。要是当初改的话，我只用添加几条代码就可以了。

其实这两种原因都能归结为一个：程序员希望自己所设计的系统能最大范围内适应变化！

这种想法的出发点是非常好的，可是在实际中却往往不是降低了工作量，反而增加了巨大的工作量。根本原因就在于：用户需求是无限量的，你永远也无法预测客户的需求变化。

举个形象一点的例子，用户真正的需求就好比是一个1000G甚至更大的硬盘，其大小仅仅只受用户想像力的约束。而根据软件技术的发展程度来看，你现在所做的程序很可能只是能满足了用户万分之一的需求，也就是100M左右。你为了让以后可能少开发一点程序，花了很多工夫做了个10M的缓存。可是你想想，10M VS 1000G，你的缓存命中率有多高？

即使不是做项目而是做产品，也不能妄自猜度用户的需求。一个好的产品的功能完善也是从初始的最简单版本开始，不断的从实际使用中接受用户的使用反馈，通过无数次的迭代而产生的。不可能有任何一个产品在第一个版本的时候，就凭着几个设计人员的想像，就把用户的需求考虑的面面俱到，完美无缺。

另外软件是一件非常讲究实效性和成本的产品，想推出最完美的产品当然没错，但是要考虑当我们在做这些“完美”产品的时候是否会加长实现的时间和成本代价。

道理说了一大堆，但是实际做起来就是非常难。Agilelabs Team内部在开发过程中也经常会讨论某项设计是否过度，有时候就连我自己其实也经常犯这样的错误。有时候回忆起自己当初洋洋自得的一些设计，确实有一些不必要的过度设计在里面。

过度设计的尺度很难把握，错误人人都会犯，犯错误没什么要紧的。但是关键在于是否有勇气推翻自己花了许多心血的劳动成果，做到这一点非常难，但这确实是我们开发人员的基本素质之一。据说John Carmak在写Doom的时候曾经整整全部重写了8遍代码，那时候还是用汇编，真是让人佩服。

程序员和项目经理的矛盾往往在于对技术方案的争论。程序员一般会按照自己的理想提出一个比较“完美”的设计方案，而项目经理则更加关心项目的完成时间。我现在更加深刻的理解项目经理的想法。许多人说项目经理可以不懂技术，但是如果不懂技术怎么能评估“方案”的好处和实施成本？错误的否决一个优秀的技术方案和采纳一个错误的技术方案都会对项目产生致命的影响。