如何看待企业自主研发框架

1. 关键有几个公司有实力能够造出轮子。。。
2. 我现在是怀疑一些公司这种管理层的真正目的。。。

我以前的公司也是如此，高层天天嚷着“要搞自己的框架”，“要积累自己的技术”，不知道哪里搞来什么博士，硕士一堆人。。。结果呢，改了下struts，成了四不象（当然不言而喻，没有struts好用，开发效率大不如以前，而且引入了致命的错误，坚持项目中要采用，导致公司大量走人），然后领导层天天就嚷着自己的丰功伟绩。。。终于知道目的了，说白了，就是瞎折腾，做和尚撞钟，对于他们，折腾点事，一年就过去，一年几十万就到手了，要是能够折腾个几年下来，就可以提前退休了。。。

我赞成根据公司业务面对的常见领域，选择合适的框架，提炼出一套适合自己的最佳实践和一组规范，然后不断积累丰富技术成果——比如提炼出可以重用的业务模块、组件等等。

不知道这里有多少是做过研发管理的。。。

企业做到一定的规模，肯定会积累出自己的平台，这不是要不要的问题。SSH只是最基础的研发框架，到业务系统之间，还需要一个业务研发平台。

研发人员是在业务研发平台之上作研发的，而不是直接在SSH之上做。事实上好的公司应该完全屏蔽底层实现细节，比如SSH，让研发人员在业务平台上开发。这样底层使用SSH，或者其他什么技术，研发人员是不需要了解的。

哈哈，很有意思哦，不错不错；有同感

个人感觉，每个公司的业务，只有自己最熟悉，为什么不可以有面向自己业务的；个性化得框架呢？呵呵

很支持。

公司的核心竞争力是什么？如果你拿这个问题来问老板，我想没有哪个老板会回答SSH。绝大部分公司的竞争力绝对在于它的软件产品能不能满足用户的业务需求。只有少部分的大型公司，敢于回答竞争力来自技术的先进。也只有这种公司才有能力，有必要自己造轮子。大部分的公司，等你的轮子造出来，也该倒闭了。

不要一谈框架，就非要把框架说得那么大，那么复杂，那么完善，什么都支持的才叫框架。

平时公司做网站开发的，简单将jdbc，常用的方法包装一下，写代码简单一些，也就是一个框架了。

能用，适合自己用的，就是好框架。

好的工具，好的框架，用得不好，写出来的代码一样差，难以维护。

如果企业觉得研发一套框架，能够在某些通用的地方提高效率，同时也方便维护和别人接手，就行啦。不一定要面面俱到。

说到底，能够最快完成项目，能够最快赚到钱，就OK。
程序写得不好，效率低了，直接跟客户说，维护不了，只能重新开发，再收一次升级费，否则一套系统稳定用几十年，公司个赚个鬼钱

这里的框架我理解为公司进行业务开发的基础平台。为何要基础平台，其实很多公司都会遇到类似的问题。
我在一篇博客中讨论了这个问题，见http://yimlin.iteye.com/blog/379897
这里也说说我的观点：

应用系统的设计可以说是将一个业务语言翻译成程序语言的过程，这个过程同时处理两个内容：业务和技术。

1. 学习业务，编写的代码符合用例的流程；

2. 学习技术，编写的代码符合技术平台的规范和要求。

这里不同底层技术的难易度不同，导致学习成本、开发成本和应用成本也不同。同时对于一个有较长生命周期的软件项目或者产品，其依赖的底层技术的升级也会带来相应的维护成不

面对特定领域的软件项目或者产品，其所依赖的底层技术的广度和深度相对稳定，基础平台可以填平或者减少技术层面的鸿沟。



那么，我们就面临另一个问题，即：业界已经存在大量优秀的开源框架，我们为何要基础平台。

首先，大量优秀开源框架可以帮助我们，但是：

1.优秀的开源框架通常偏向通用性，而面向特定领域的相关特性和功能还不支持；即便有面向特定领域的，其支持的特性还存在一定差异性；同时其未必支持相应的基础设施。

因此需要进行二次开发，以完善所需的基础设施；

2.优秀的开源框架在通用性支持广泛，提供多种选择，同时还有一定学习成本；而面向特定领域，需要的模式相对固定。

因此需要进行定制，减少学习成本，提供开发模式，进而提高开发效率；

3.技术升级的平稳性，虽然优秀的开源框架会尽量提供升级平稳性，但是和产品目标未必一致；也需要进一步的测试工作；为了进一步减少成本和风险需要基础平台来处理相应工作；

4.开源框架本身存在一定的缺陷，其修复有一定周期，和产品项目周期不同步。所以也需要做些修复和规避工作；

因此开发维护支持特定领域的基础平台存在客观需要。更进一步，基础平台是在关注点分离原则下的一个必然产物。

没有特殊原因请'不要重复发明轮子'