一次和老总去吃饭，等了很长时间，饭菜却迟迟没有上来。
我们俩都很生气，这时候老总借景抒情的说：“我们做软件的时候，就象开饭店一样，要尽量满足”吃客“的要求，尽管后来，饭菜还比较可口，但是因为等了老长时间，以后我们就再没有去过那家店。
作为一个程序员，尤其是一个水平比较高的程序员，他的思维逻辑一般是比较抽象。而在设计软件的时候往往会出现想当然的想法。比如，在角色权限设计方面，一般情况，角色权限可以分为两种1）针对行和列的权限策略，这种权限策略非常详细。2)针对模块的权限策略，这种权限策略比较宽泛。只是限制对模块级别的访问。两种方法个有千秋，不能说那个好，那个不好，但是如果在错误的环境下应用了错误的策略的话，
最终用户使用起来可能就比较吃力。比如，在一个银行系统中，出纳可以查看客户的卡号和帐户余额，还有一些其他信息，而绝对不能查看用户的密码，此时如果采用针对模块的权限，那实现起来就比较困难。而对于类似给一个规模较小，职责比较集中的OA系统来说，如果采用行，列授权，当然能够严格保证系统的安全性和操作性，但这样的环境一般不会有专门的系统维护人员，而系统配置起来，就可能比较麻烦。
这时候，我们复杂的实现也许给客户带来的是繁琐和不解。最后相反会被一些简单的系统所淘汰，就像java中间件里面，spring大有代替ejb趋势一样。同样是权限管理，在授权的时候，可以单一为角色授权，另一种可以为角色授权，也可以为单独用户授权，从实现来说，单一为角色授权比较简单，但是在使用的时候，由于设置权限的方法比较单一，用户容易上手，某种环境下，可能比复杂实现的系统更加受欢迎。
敏捷软件开发宣言中有一句话：”相应变化，胜过 遵循变化“。原则中也有一项：”即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势“，其实这些都是要求我们以客户的需求来设计我们的软件。如果能在遵循需求的基础之上，加上自己的经验，设计出即简单，又满足功能要求的系统，那就更好了，但是千万别单单评自己的直觉，设计出一些”符合程序员的逻辑，不符合人类的逻辑“的程序。这样，我们可能很费力，但用户还可能不喜欢。
|
