面子驱动编程

说的的确是事实

想解决问题还是想发牢骚？
问题的实质是什么？
设计不足？过度设计？公司的面子？业务人员面对客户时的谈资？

楼主，我的观点和你不太一样。
1.别太相信客户的话
  客户的需求他说不会变，就真的不会变吗？
2.从设计角度讲，前面有几位兄弟已经说得挺多的
  从代码重用与设计重用的角度，一开始就把权限模块做成通用可配置的，是很不错的。
  可以灵活应对客户各种的变更(某客户说：“小伙，我想在这里多加一点东西”)
  实施的时候，也非常方便
  假如有变更的话，配置后就可用，无需测试(现在写死的，测试是少不了的，万一有bug，那个痛苦只有自己知道)
3.说一点你那个小组长的“面子”
  其实这里跟面子一点关系都没有，真的，呵呵
4.这一点说多了，呵呵，可能不该说
  如果楼主在设计方面不下点功夫，再过四年，您可能还在做程序员
  无法升到做系统设计或者更改层面的事咯

说的有道理，角色确实是可以写死的。

我一般的做法是把角色写死在数据库里，不提供给用户修改。

而针对于角色的权限配分是可以由用户来设置的。

晕。典型的，典型的，没有设计。这些问题都是因为没有前期的设计。

我就郁闷了，怎么设计交给了程序员？？？需求都没有搞清楚就可以开发？而这些需求还得由程序员来设计？

面子驱动 很形象   
为了 面子 可以把“很烂的东西 说成 很灵活的东西 ”

看了大家的回复，我感觉有些东西可能没说清楚。我这里补充一下：

关于面子：其实小组长问我的时候，项目经理也在边上听。最后是我坚持这样做，他们也不能把我怎样。

关于权限：现有的权限管理是一个单独部署的模块，而岗位变更，又是第三个模块里面的。绩效对它们只能读取。一旦“重用”了这套权限，那么岗位变了以后，用户还必须进入权限管理，将这个人的角色改掉。更重要的是，管理岗位变动的用户很可能不是管理角色的那位用户。一旦两边不通气，事情就麻烦了，而我一点办法都没有。绩效模块涉及很多员工，这些员工岗位调动比较频繁，所以我直接选择岗位而不是角色。希望大家以后碰到这样的模块化项目千万别设计成这种样子。

关于变化和灵活性：不错，用户说的不能尽信。所以我也是在充分了解用户的基础上作出判断的。根据用户的岗位来决定权限，这也是灵活性。把权限的判断交给岗位还是交给角色，对绩效模块来说没有本质的区别。至于将来怎么改，谁也料不到，所以还不如花点精力把现有的东西写得清晰一点。另外，还是有人有这种误解：好像我是在牺牲代码质量。这完全把我的态度理解反了。——功能灵活就表示代码质量高吗？

关于规范和标准：规范和标准不能代替设计。特别是模块的业务逻辑设计，编码规范怎么管得了。

我们不像那些大公司，我是需求设计连编码一起做的。我个人觉得这样还好，既长经验，又省得心里没底。

我做需求的那个用户，态度相当好，宁等三分不急一秒。一来他自己就是要用这个系统，二来他也知道我不是为了做完交差，而是真心实意的希望这个模块能给他们带来便捷。

仔细一想，这也算是一种面子驱动哈……

ZF的项目都是做的玩的，只有有页面他们能交差就可以，根本没什么人用。项目对他们的意义就是评科技奖和吃回扣

晕爆了,这和面子有什么关系...
如果你有一个灵活的,可配置的模块,是可以轻易融入其他项目的.
ZF面子工程很多这不假,但那始终是别人的事情,作为程序员我想我们应该对自己的作品抱着精益求精的态度吧....

不说了,大道理了.总之我觉得平时对自己要求高是好事

个人认为，如果公司有一个有关权限管理的成品，大可以扩展这个component来适应lz的客户的需求。adapt，template，command都可以来帮助楼主实现这个需求。
松耦合啊，松耦合～～
不要把代码写的太死哦，这样以后维护你代码的人要对你腹诽多多，你会整天打喷嚏怀疑有人在“想”你了。
呵呵。