面子驱动编程

组长的决定不一定是“面子问题”吧？ 就这么给人家定性了？！


看的出，你们公司有现成的关于权限的数据模型，那还是能用现成的就尽量用现成的（很反对那种忽视现有资源的做法，不职业，不高效，也不利于积累）



既然客户不需要那么灵活的配置，那你为什么又提到这种情况:“用户在变更岗位之后还要手动更改角色”？是不是有点儿矛盾？

    其实，上面所讨论的“过度追求灵活”、“过度设计”的害处，没什么问题。其实大家都知道，别说四年工作经验了，刚开始工作就可以有这种意识。
   
    问题是：写成可配置的，相比写死来说能麻烦多少（当然，不给用户提供配置界面）？
    我的理解是：你最开始写成“可以配置的”——也就是通过修改数据库里关于权限的记录，就可以更改某个岗位可以进行的操作——这样，在上线之前，如果用户提出这方面的变更，你修改起来就很容易，更重要的是：与写死相比，这种修改不容易引入新的bug。到系统上线的时候，你根据用户最终确定好的岗位情况，准备好一个数据初始化脚本，一执行，就设置好了。
    如果用户在使用过程中，认为需要增加一个岗位，这个新增的岗位原来认为是与另一个岗位是一样的，但使用过程中发现有几个小操作还是不允许他用好一些。那好，那就升级系统呗，其实对你来说，只是修改一下权限表的数据。

    不用一开始就做的那么灵活，但也不代表就得一下子写死。你不想用那些权限表（省去dao），那可以在service层写死——至少先把位占上。需求有变动，大不了修改这一个类呗。

我们也有这种情况，刚做完一个项目，一闲，领导就说，你们要把这个系统包装成一个产品，然后就是IF`````THEN``````。意思如果我们做好了，那可就牛了，能怎么怎么样了，一点不提怎么做，多少资源，多少时间，多少费用，要不就说，我们一定要`````。见多了就明白了，想法是好的，但不想投入，于是广撒种，不浇水施肥，万一有那个长成了，那领导就来摘桃。

呵呵，深以为然。

再现幽灵需求

同问……

LZ的小组长不是以前一直合作的吧？如果是一直合作的，这个问题应该不会提出……

另外，小组长，这个职位的概念是啥……

正在进行中....

同志们，开发一个系统，不能仅仅是照本宣科完成客户的需求，还应该由业务专家领头，从用户角度出发，设想他日后可能的变动和升级，在设计上做适当的准备，或是作为附加的亮点功能提供给客户，为自己的软件在客户心目中多加点分..

是不是过渡设计还不好说，一定程度的灵活性还是需要的，你真的无法保证需求铁定不会变。

反正做B/S系统，
权限控制，I18n, 这些我觉得自然就应该有的，而且人力成本并不高。
在ruby on rails下，一个勉强可以用的权限控制费了我几个小时而已(可能很多人还嫌我太慢)。 当然如果用户要求到 某个column某个record的安全性能我暂时还没想好怎么做。