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

最近公司在开发框架选型的问题上出现了争论，特发帖征求各位大大建议。
在第三方如此盛行的今天，大家做项目都是
1、基于现有的第三方框架组合封装来开发
2、自己写一套框架来支撑
还有个目的就是公司想在开发的过程中对知识的积累，便于二次开发利用开发，所以就要求基础框架必须具备扩展性。
在没有特殊业务需求的情况下大家会怎么选择。

评论

46 楼 Durian 2009-05-25  

这个问题跟公司规模和未来的发展方向密切相关，如果不是很大，为了解决温饱不计成本，也不管什么类型项目都接的公司，就没必要自己搞一套平台软件，否则就应该有自主姿势产权的框架。

45 楼 smilerain 2009-05-25  

1.你们公司人员稳定,
2.你们的技术相当的牛.
3.公司能够长期支持.
4.现有构架不能够满足你们要求,或者你们有非常优秀的想法.

满足的话可以

44 楼 ironsabre 2009-05-25  

企业的真正核心是在业务行业上面．

用任何框架，最后的难点都是在处理实际业务上．

我们公司用的是十年前的jsp->servlet模式，可我从来没有因为这个东西困扰我．

困扰我的是那些真正的实际的业务问题．

43 楼 yajie 2009-05-25  

有能力的公司造个轮子不算什么，没能力的公司掂量掂量再说。
没必要争论不休了，有能力早就做了，还在这里浪费口舌？
从我这里结贴吧。别再废话了，留些精力继续创造吧！

42 楼 mniz 2009-05-24  

补充一点，如果是不错的到还无所谓，我公司用的什么垃圾框架，整个就是把hibernate+spring 给封装了一下，我*** 底层的还是用的原有的东西，只不过我们的框架特点是在页面上

41 楼 mniz 2009-05-24  

readythink 写道

公司自己的框架对于新进员工来说还有个学习成本哦,可怜的就是这些打工的,学过来学过去,什么时候也造几个轮子让别人试试这个苦头.

严重同意，我们公司就是用的自己的框架，用的时候特别郁闷

老是问，非常非常的郁闷

40 楼 jw2007 2009-05-24  

我也是觉得，自己造轮子，和给公司用自己造的轮子是两回事。

39 楼 Robinson. 2009-05-24  

yajie 写道

有能力的就去做，少说；没能力的就去学，少废话。

前面的人都说的很有道理了，公司的实力不够的情况下自主开发无疑是自找麻烦，谁知道你能多久开发出来，并且就算开发出来，若只是自己的公司用，那么新人进入公司上手又要麻烦点，长期下去会弊大于利的。

38 楼 yajie 2009-05-24  

有能力的就去做，少说；没能力的就去学，少废话。

37 楼 chandler 2009-05-24  

jnn 写道

chandler 写道

jnn 写道

chandler 写道

    如果一味的因为害怕早轮子，或者一味的觉得如果造不出天下第一的轮子，我们就不造轮子。最后的结果肯定是我们一个轮子也造不出来。
    几个讨论的误区就是在于造出来一定要用，一定要怎怎么样。当然，一个企业不能够不考虑成本和收益。但是冰冻三尺，非一日之寒。如果要要使得我们整体水平上去。肯定需要一批批垃圾的框架做铺垫。
    如果真的要写的话呢，我觉得有两个问题要处理好，一个是文档的整理。一个是需求的分析。需求应该以技术需求为导向，而不是业务需求。

如果你有足够的×资源×以及×能力×造轮子的话，那就造轮子吧。

不过建议你想一下当下这么多开源软件， 有这么多的大牛在那里推动， 如果你能真正用好这些开源框架 （提交patch， 按照你的需求添加新的功能）的话，就可以把你的核心竞争力表现出来。 这和你从头开始造轮子要简单，有效很多，而且成功的可能性也要高很多。

    我和你站的观点不同。
    我同意你的方面是如果站在就单个项目来说，利用现有的成熟框架，是能起到事半功倍的目的。
    但是明白一点的就是，长期下去，弊大于利。因为我们没有国外的那些框架，我们不能做事情，或者说做不好事情。但是如果他们没有我们，他们可以找到更便宜的劳动力。
    所以我觉得，现在企业的自主框架应该放在一个长远的目标上面。只求做成，不求做好。因为任何技术的发展都是循序渐进的。我们的差距摆在那里，肯定不可能一下子做出和国外相媲美的作品。就索性利用项目的间隙期，来做做自主的框架，一来锻炼一下，二来也不会让人停滞下来。
    最后，我觉得不要妄自菲薄。很多时候那些大牛们做的框架是完备。但是大牛们也是从无到有慢慢成长起来的。如果就把他们的东西拿来用，拿来学，而不产生自己的东西。他们永远是大牛。

   请注意，我观点是要用好开源框架，把它们变成你自己的代码， 不是简单的使用开源框架来做项目。
   开源框架的优势就是没有代码壁垒， 只要你愿意研究，有想法，而且足够勤奋的话就可以成为开源框架的大牛。
目前国内企业的很多“架构师”只看见开源框架免费的好处，没有看到加入开源社区的开发对其技术成长所带来的好处。
自己做开源软件目标很好， 但是不太现实， 除非你只打算做一个玩具框架出来。
   如果你想做一个真正有人用的框架，为什么不从给Spring 打patch开始呢？

  

      怎么说呢，我不否认你的观点。我只是觉得不能完完全全的依靠别人。
      不知道你理解你的意思对不对，你觉得现在最好的方式是完完全全的依靠现有的框架或者别人的肩膀上来做事情。现阶段，我是部分支持你的这个观点的。毕竟完完全全的自主研发，对企业，对个人来说没有一点好处。毕竟我们没有能力做好一个基础的有用的东西。
      我只是觉得，我们不能完全放弃基础的这一块，而把这些都借用别人。因为这样长久以往，我们更本无法摆脱对别人的依赖。尽管我们做的很幼稚，很没有用，但是也要有一点自己独立于别人的东西。

36 楼 vlinux 2009-05-24  

fight_bird 写道

]2、技术框架和核心业务紧密结合后，一个行业解决能力的概念就出现，这就可以称得上核心能力——能够创造价值且别人没有的，“核心技术”这个词是外行叫法。

虽然我不同意fight_bird的主要观点，但是这点对我影响很大，受教了！

35 楼 kjj 2009-05-24  

有钱，有时间，有空间，完全可以造，提高水平嘛，老用人家的自己只能去学不熟悉的专业业务知识，挣外行的钱，早了轮子，好点的话，就可以挣自己人的钱，这比挣不了解的人的钱可容易多了！！

34 楼 jnn 2009-05-24  

fight_bird 写道

做出一个技术框架不是什么大不了的事，但要做好，做到足够商用的地步就不是容易的事情，否则，你就是拿自己的技术冲动害人误事。

大大小小做过5个技术层面框架，但也只有一个框架持续发展、成熟起来，成为公司首选的商用框架，整个过程持续3年多，其中个人投入的精力就无法累计了，就我的经验和教训，一个能够商用的定制框架必须具备以下几个要素：
1、技术层面可信赖，无致命的技术缺陷，如内存泄漏、并发死锁、低性能、高资源占用等、调试低效、测试低效，这是基本要求。
2、等于或高于主流开源框架的开发效率，至少没有明显的短板，包括编码、需求变更响应、售后维护、测试诸多环节，这是商用价值最直接的体现。
3、成熟的组件库，包括UI组件、中间层组件、持久化层，这直接保障上述两点的实现，一个“裸”框架是没有价值的。
4、完善的文档库，这个的价值不多说，谁都明白。
5、可以被验证的成功项目实例，一开始只能在小项目中使用，逐步推广，没有谁一上来就敢在大项目中使用你的自定制框架。

自定制框架的不利影响上面很多人都阐述了，我就说说自定制框架的好处：
1、all in hand，一切都在掌握中，技术挑战和问题可以高效、灵活应对，很多人都有过因为开源框架使用过程中的技术问题到处找人、找资料解决的经历，其实每个开源框架都存在这种不可控的风险，这些弊端在自定制框架上不存在。

使用开源框架是有这个风险的， 不过这个风险是可以规避的。
如果你都有相应的资源来自己开发框架了， 那你完全可以请 开源软件公司来做咨询 或者 买开源软件的服务。
因为你要做好前面的1，2，3，4，5 所投入的资源 要比后面请专业人事来要多得多。

引用

2、技术框架和核心业务紧密结合后，一个行业解决能力的概念就出现，这就可以称得上核心能力——能够创造价值且别人没有的，“核心技术”这个词是外行叫法。
3、开发效率高，这个和第一点是一致的，从核心层到UI层，你想怎么提高效率，你就怎么设计，只要你能想到......

33 楼 jnn 2009-05-24  

chandler 写道

jnn 写道

chandler 写道

    如果一味的因为害怕早轮子，或者一味的觉得如果造不出天下第一的轮子，我们就不造轮子。最后的结果肯定是我们一个轮子也造不出来。
    几个讨论的误区就是在于造出来一定要用，一定要怎怎么样。当然，一个企业不能够不考虑成本和收益。但是冰冻三尺，非一日之寒。如果要要使得我们整体水平上去。肯定需要一批批垃圾的框架做铺垫。
    如果真的要写的话呢，我觉得有两个问题要处理好，一个是文档的整理。一个是需求的分析。需求应该以技术需求为导向，而不是业务需求。

如果你有足够的×资源×以及×能力×造轮子的话，那就造轮子吧。

不过建议你想一下当下这么多开源软件， 有这么多的大牛在那里推动， 如果你能真正用好这些开源框架 （提交patch， 按照你的需求添加新的功能）的话，就可以把你的核心竞争力表现出来。 这和你从头开始造轮子要简单，有效很多，而且成功的可能性也要高很多。

    我和你站的观点不同。
    我同意你的方面是如果站在就单个项目来说，利用现有的成熟框架，是能起到事半功倍的目的。
    但是明白一点的就是，长期下去，弊大于利。因为我们没有国外的那些框架，我们不能做事情，或者说做不好事情。但是如果他们没有我们，他们可以找到更便宜的劳动力。
    所以我觉得，现在企业的自主框架应该放在一个长远的目标上面。只求做成，不求做好。因为任何技术的发展都是循序渐进的。我们的差距摆在那里，肯定不可能一下子做出和国外相媲美的作品。就索性利用项目的间隙期，来做做自主的框架，一来锻炼一下，二来也不会让人停滞下来。
    最后，我觉得不要妄自菲薄。很多时候那些大牛们做的框架是完备。但是大牛们也是从无到有慢慢成长起来的。如果就把他们的东西拿来用，拿来学，而不产生自己的东西。他们永远是大牛。

   请注意，我观点是要用好开源框架，把它们变成你自己的代码， 不是简单的使用开源框架来做项目。
   开源框架的优势就是没有代码壁垒， 只要你愿意研究，有想法，而且足够勤奋的话就可以成为开源框架的大牛。
目前国内企业的很多“架构师”只看见开源框架免费的好处，没有看到加入开源社区的开发对其技术成长所带来的好处。
自己做开源软件目标很好， 但是不太现实， 除非你只打算做一个玩具框架出来。
   如果你想做一个真正有人用的框架，为什么不从给Spring 打patch开始呢？

  

32 楼 logicgate 2009-05-24  

如果是大公司的话可以考虑这么做。就像金蝶，搞了一个自己的Apusic应用服务器。做应用，做项目的小公司一般没有能力，也没有必要从头开发框架。

对于小公司，建议基于现有框架，结合内部开发需求进行封装，扩展。

31 楼 fight_bird 2009-05-24  

做出一个技术框架不是什么大不了的事，但要做好，做到足够商用的地步就不是容易的事情，否则，你就是拿自己的技术冲动害人误事。

大大小小做过5个技术层面框架，但也只有一个框架持续发展、成熟起来，成为公司首选的商用框架，整个过程持续3年多，其中个人投入的精力就无法累计了，就我的经验和教训，一个能够商用的定制框架必须具备以下几个要素：
1、技术层面可信赖，无致命的技术缺陷，如内存泄漏、并发死锁、低性能、高资源占用等、调试低效、测试低效，这是基本要求。
2、等于或高于主流开源框架的开发效率，至少没有明显的短板，包括编码、需求变更响应、售后维护、测试诸多环节，这是商用价值最直接的体现。
3、成熟的组件库，包括UI组件、中间层组件、持久化层，这直接保障上述两点的实现，一个“裸”框架是没有价值的。
4、完善的文档库，这个的价值不多说，谁都明白。
5、可以被验证的成功项目实例，一开始只能在小项目中使用，逐步推广，没有谁一上来就敢在大项目中使用你的自定制框架。

自定制框架的不利影响上面很多人都阐述了，我就说说自定制框架的好处：
1、all in hand，一切都在掌握中，技术挑战和问题可以高效、灵活应对，很多人都有过因为开源框架使用过程中的技术问题到处找人、找资料解决的经历，其实每个开源框架都存在这种不可控的风险，这些弊端在自定制框架上不存在。
2、技术框架和核心业务紧密结合后，一个行业解决能力的概念就出现，这就可以称得上核心能力——能够创造价值且别人没有的，“核心技术”这个词是外行叫法。
3、开发效率高，这个和第一点是一致的，从核心层到UI层，你想怎么提高效率，你就怎么设计，只要你能想到......

30 楼 neora 2009-05-24  

还是试试造一下吧，否则你们怎么知道自己造不出来呢？

29 楼 treblesoftware 2009-05-24  

撇开造轮子的问题不说。从无到有，本身就是个很复杂的过程。当然，如果你拿别人的代码来COPY，那另说。

28 楼 Joo 2009-05-24  

对楼主所在岗位比较好奇，一般这种事情应该是基础构架组或者核心成员，不知道楼主是什么位置，有投反对票的权限吗

27 楼 betafox 2009-05-24  

听起来大家都倾向于直接使用开源组件，组合起来就行了，不需要再自主研发。对于这种观点我持保留意见。
我在具体的项目开发中使用过多种开源组件，个人的体会他们的共性问题是：开源框架是立足于某一类问题提供通用的基础的解决方案，对于特定的问题域、业务域其通用性造成的后果是开发效率无法发挥到极致，各组件无法密切配合、总存在互相掣肘的地方，所以我认为基于基础开源组件，定制、整合、瑞色、再加上对自己特定领域制定一些契约，屏蔽一些技术细节，才能将效率真正发挥出来。。。。