面子驱动编程

做啥，也别做电力的项目。

原因如下：

1.电力用户不喜欢提出需求，他们会让开发商按照自己对电力业务的理解和实际情况编写需求。然后在一个确定的期限内，连同项目的第一版和需求说明书一起提交给电力用户批改。他们如果觉得你做的不对，他们会根据你做出来的东西提出具体的变更要求。

2.变更，就像拥有无穷个叶节点的二叉树，可以拼命的分叉。但是从层级关系又会转换成链表方式。需求就像一个无底洞。领导一拍脑袋，需求就得变。至于这样改变是否符合用户的最终要求……等你改好之后给用户看，刚做的改动十有八九会被推翻。

3.集成，SOA就像是一剂毒药。大型企业不论是否真的有必要实施系统集成，全都要往SOA上靠。因为这样才代表最先进的生产力。

4.用户是领导，领导是用户。用户永远是对的，领导的权威不可动摇。对，是领导有方；错，是执行不力。变更的时候，说“简单”的，都是不干活的；说“复杂”的，都是“累死累活”的；说“没问题”的，都是小领导……

5.拍板定案的，不组织工作开展；组织工作的，都是没有级别参加“拍板会议”的。

6.……

还有很多，想给电力企业搞开发的话，最好先打听清楚，以免深陷泥潭。

有些是属于“一般功能性需求”和“非功能性需求”的范畴，用户即便没有要求，也应该考虑到。

权限就应该做成灵活可配置的，不然还要权限模块干啥？直接在人员表里加属性标志位不就行了？

赞同！

1. 权限这玩意还需要每次都设计一遍吗？用户和角色的多对多关系是不用多说了，唯一需要分析的地方就是功能点的粒度，可能是按页面，action，method，等等。
2. 项目里要不要把权限做死的问题，其实真的跟技术无关。而是跟利益有关，作为程序员新手可能想多做点练练手，老手可能学会以后又想老做这个没意思，可能小组长觉得这个都不做还能算个系统吗，可能工期很短，做完以后反正也不是你维护，你可能已经收到了新的offer，

总结得不错，不过要理解市场，没有点花哨的提法是不太好跟人说，不管怎么样，一个产品多少得有几个亮点，最好的选择就是那种容易做，但实际上应用得不怎么多的功能来玩，对程序员而言，就当作练习好了。

把编译时和运行时分开，把静态和动态分开，把元数据和普通数据分开
这个不是面子的问题，而是一种思维习惯
有了合适的工具和方法，两者在速度上还不一定谁比谁快

以前读UMl书籍的时候，记得有句话说，我们要把狗窝当作大厦来建。
这位兄台，现在有项目时间，有计划，却要将大厦盖成狗窝？

所谓需要是无限的，只着眼眼前的状况，完全可以不要大多数的文档，所谓的规范
，灵活性。
只想说一句，不能盖一辈子狗窝啊！

我觉得也是啊 权限系统非常重要,客户可能嫌麻烦,还看不到这样的需要,以后系统使用的人数以及角色多了之后,肯定会考虑的,这个时候你要是再去做一个权限控制,就会带来大量的工作量,甚至有可能导致项目失败.而且完成一个权限系统也可以一劳永逸,以后再遇到类似的系统开发任务直接拿过来用了 .

饱受进度驱动的折磨啊。

本帖真正精华