面子驱动编程

满足需求，但防止镀金。又一个案列～

稍微大点的公司都这样
项目都是做为上面看的
项目在短时间内赶出来了，领导有面子了，这就是绩效啊，说明领导管理有方
说明领导可以在年底多拿点钱
具体实施的程序员类，就累的要吐血了，有的时候一个功能用户根本不会那么使用，费用做出来，做到后面都没办法维护了，真是无语

最近又碰到一个项目，不过是一个网站而已，竟然要用到 JBoss ESB

看了讨论发现LZ真郁闷， 对牛弹琴嘛

不是有那个境界一说，

看山是山，
看山不是山
然后看山又是山。

Lz一直强调他是在第三层得基础上来讨论的，结果很多人一直劝LZ要看的远一点，要看到第二层去。

我们现在也在做你所说的面子工程,但是还是有必要性的.不同的项目都共用了,能减少很多开发量.

事实是，LZ不应该站在他自己的角度上看这个问题，显然你程序员做出来的东西是公司的不是你的（业余时间搞出来的开源项目另说），对产品的评估当然也必须站在公司的角度来做。显然，一个被你写死了的功能对于公司来说是不可接受的，把公司的项目或产品绑架在你个人身上怎么可能被公司接受。

我没那么不负责任吧。难道不是我的我就不管了？你哪里看出来这个东西绑在我身上了？现在我已经跳槽了，那东西交接得好好的，几个月来没人因为设计上的问题找我。

我没说过你是不负责任的人呀，但万一交接不好人家回来找你，你又很负责任，岂不是累死自己？
前面说过，没有看到具体实现，不可能判断到底是小组长过度设计还是LZ写得太死，我只是从小组长的角度来看这个问题，并且认为他的担忧有足够的道理，你可能对自己的设计很有信心，但不能强求所有的人对你那么有信心。
我见过交接做得差的，结果非常非常的糟糕，作为小组长，这种担忧绝不是多余的，你如果已经当上了小组长，很快就会明白了。

要从小组长的角度看问题，那就四个字：用人不疑。你担心可以，你提建议可以；但你想插手，这事情的性质就不一样了。另一方面，“过度的一般性”真的能解决问题吗？在这里个例子里，权限设计同用户工作方式不一致的弊病已经显现出来了，不能再走下去。

怎样的设计才既灵活而且又不过度？