Keep It Simple and Stupid！

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

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

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

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

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

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

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

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

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

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

扯远了点。任随思维的跳跃，随手写了这许多，算是对今天关于权限系统设计讨论的一个心得记录。

今天讨论中我提出的一个简单设计的原则就是：只添加目前需要用到的代码，目前不用的代码就不要写，等到以后要用的时候再写。

希望敏捷实验室能在一次次的讨论中提高自己根据技术方案结合项目的进展要求情况，能综合各种因素提高对设计尺度的把握能力。

文章来源:http://www.agilelabs.cn/blogs/linkin/archive/2006/01/02/450.aspx