灵活性问题

看到论坛上不少帖子谈论到FrameWork的灵活性问题，其实FrameWork的灵活性对于不同的人重要性是不一样的。
技术水平较高的人可能会希望FrameWork的灵活性高一些，这样他可以有更多的发挥，但对一般的编程人员来说，灵活性小确实一个更好的选择。
今年做了两个项目，第一个项目的FrameWork灵活性很小，给程序员的选择非常的少，结果项目完成质量很好。第二个项目正在做，所用的FrameWork自由度很高，一个处理可以有多种实现方法，结果是source写的很乱，苦不堪言，
所以对于在短时间内要求很多人大规模的开发的项目，灵活性很小的Framework是更好的选择。我以为。

同意，不过觉得自己是高手的同志们，都喜欢更加灵活的。

你犯了个常识性错误：大多数程序员不是在raw框架上开始工作的。总是由少数核心架构人员建立vertical slice，检验技术可行性，再搭建一个template application，把infrastructures封装起来，其他人在template application的基础上编写业务逻辑。对于大多数程序员来说，框架灵活与否他们根本不必关心，他们只要写出符合OO原则的程序就可以了。而对于架构者，当然希望框架更灵活，这样才能针对每个应用的独特需求搭建更合适的template application。

在我们的team里，大多数人接触到的是utils，而不是frameworks。不管你用什么util，总之你保证你是在针对接口编程，你保证你的对象是一个标准Java Bean，你保证你的对象能通过单元测试就行了。architect自然会把你的component组装到整个系统中。如果每个程序员都必须知道Spring框架的方方面面，这个项目不乱才怪。

framework本身就是一个半成品，改造后的framework也是framework,只是更有针对性。楼主提出了一个问题，而gigix给出了解决办法，不过不同意内部处理过的framework就不再是framework了，虽然它更有针对性了，但以后还是可以重用，最少在一个公司内不会重复每个项目都要改造一个通用更强的framework.

看来大家看法比较统一。

framework的灵活性应该针对不同的项目角色而不是水平，当然水平的因素在里面。对于技术选型的项目角色，当然需要灵活的框架来为项目开发打下基础，并将framework的灵活性和复杂性针对项目进行限定。对于在此基础之上进行应用开发的程序员，根本无需知道底层framework有多复杂。

这是应用层次的问题。如果有一个人能够对应用层次进行分配和管理，对相应的应用层次做出恰当的限制，相信开发质量能够得到更有效地控制。

越往高处，越应该强调通用性，越往低处，越应该限制通用性。这其实涉及到技术管理。