这个问题其实很难简单一两句话说清楚。我就结合自己的经历掰扯几句吧。
刚毕业参加工作的时候，去了一家小公司（其实是大集团控股的一个子公司，然而完全独立），公司有位特别厉害的技术总监，代码水平一流，人也特别好。当时还是 J2EE 的时代，Struts 还是 1.x ，Spring 才刚刚出现，远没有像后来一样成为 Java 企业开发的标准。后来总监自己写了一个名叫 Common 的框架，主要也是基于 IOC 和 AOP 的理念，在公司内部推广使用。感觉在 Common 框架的基础上开发公司的业务代码有种很爽的感觉，比起完全从头自己抡，在各方面的优势都很大。那个时代开源技术还不像现在这么风行，能有一个靠谱的框架使用，真是一件很幸福的事情。没事的时候读读框架源码学习学习，还能时不时的提几个 bug，贡献几个fix，不亦乐乎。
后来去了业内的另一家大公司，那家公司也有一个自研的框架，叫 Appframe。然而正因为公司比较大，这个框架在公司内部也没有完全推广开来。我大概了解了一下框架的理念，它是一个一站式的框架，感觉设计者想从头到尾就用这一个框架把整个项目都完全实现。然而给人的感觉是这个框架并不灵活，侵入性过强，也很让人担心如果用在项目中的话，能否适应快速变化的业务需求。加上存在着一定的学习曲线，所以我的团队在项目中也没有使用它，而是转而采用当时正流行的 Spring，Struts 2，Hibernate 这些开源框架了。事后看确实完全没有采用这个自研框架的必要，因为看不出来它对项目开发的进度和质量有太多正面的影响。而一旦采用，就会被局限到这个框架里，反而失去了尝试各种开源框架的机会。
再后来去了一家巨无霸公司，连 Java 都是他家的，但在团队里开发项目主要也是用的开源框架。唯一限制的是当时开发前端界面用的是 JSF。不过我自己好像也没怎么学，至少现在完全想不起来当时是怎么用的了。
再后来……因为呆的公司都比较小，就没有机会用自研框架了。而且我用到的技术也不局限于 Java，PHP，NodeJS，Python 相关的也都用了很多。还是自由的感觉比较好，碰到一个任务，可以选择一个趁手的工具来解决问题，而不是手里只有锤子，看什么都像钉子。
然后时间到了今天。去年我又加入了一家大公司，不出意料地公司也有自研框架，而且还有领导要求，必须要使用这个框架。于是乎我开始学习这个庞大的框架。框架的组件很多，我碰到的最大的问题就是文档写得不够具体，缺乏指导性，而且是内部使用的东西，也没办法自己去网上找答案，平时最好用的 Stackoverflow 也没救了。更为恶心的是，出于所谓知识产权的考虑，源代码即使在公司内部也没有公开。加上公司太大，我们和负责开发框架的同事沟通也非常不方便，无论是在物理空间上还是网络上都是分离不互通的。因此尝试用了几个组件之后我对使用这个框架就没有任何热情了……
我能理解所有公司自研框架的初衷，都是为了规范和统一代码的实现，避免业务开发中的重复劳动，也节约测试和运维的成本。然而理想是美好的，现实是骨感的。在实际的工作中，公司自研框架的开发维护人员，和实际业务的开发人员，两者的目标未必是一致的。即使靠领导从上至下的强行推广，也很可能是怨声载道，未必能对项目带来良好的效果。特别可怕的是那种大而全的框架，想一切包办代替的，这种框架往往未必满足项目的实际需求，硬要用它来开发反而就像穿了一双不合适的鞋在赛跑。磨不磨脚，只有程序员自己心里知道。
