基于开源框架做应用是未来中小型软件公司的发展趋势
在我的周边朋友身边就发生过这样的事情：
故事1：A君在北京从事Java开发好多年了，萌发了创业的念头，想组建了一个开发团队想大干一场。但是慢慢发现，构建一个有战斗力的团队真不容易。后来技术团队的组建初步有了起色，但是技术路线却非常难成一致意见。折腾来折腾去，把有点上道的技术人员都折腾得跳槽了。费了巨高的成本搞了一个架构师，就是利用SSH框架搭建了一个开发环境，数据量小，业务初期还是不错的，但是当业务快速增长的时候，运行速度就无法满足需要了。是重新来过还是在SSH的基础上继续折腾，非常难以抉择！
故事2：Jenny从英国回青岛大半年了，很喜欢青岛这座海滨城市，空气很好，周围的一草一木也很亲切，这也是当初为什么回来的原因之一。不过，Jenny一直在为产品管理的事情焦头烂额。除了开发成本高，软件层次一直比较低。产品团队管理之外，还要考虑技能水平、分工、角色岗位、薪酬、性格特点等等，各方面都耗费了大量的时间。由于缺乏大规模的压力测试，花了大量时间做出来的产品，却不能适应海量数据下的大并发访问。想找一些高手吧，在软件业本来就不发达的二线城市又不太现实；离开二级城市转到一级城市发展吧，又承担不起高额的运营成本与人力资源成本，路在何方真的是个问题！
故事3：经过大半年的筹备，阿灿的技术团队终于组建起来了。不过，人员流动始终是个挥之不去的话题。换了人，技术方案就要换，随之而来的维护问题也是让人焦头烂额！阿灿沮丧了，他怎么也想不明白，为什么新来的人就不愿意继续在老人留下来的系统上进行维护和再开发呢？如果才能建得起来铁大的营盘？
类似的故事，不胜枚举。总结一下问题出在如下几个方面：
1. 人员培养速度缓慢。从人力资源团队的角度来讲，更多考虑人员的职业道德是否符合企业文化和价值观。而软件开发项目经理更多考虑的是，新成员是否能够为软件开发项目做出贡献，并符合项目文化和价值观。如果你的软件开发团队都不是自己亲手组建起来的，你又如何能够保证软件开发团队能够按你期望的模式运作？应聘人员通过各种认证，仅仅代表具备了基本的知识体系和理论基础。但任何认证都无法真正体现出每个人的学习能力和应用知识的能力，而这两点恰恰是软件开发项目最关心的技能。尤其是，要成为一个优秀的软件架构师，往往需要具备10年以上的软件开发经验，入门的门槛是相当高的，尤其是在互联网产品愈发重要的当下，一个软件架构师往往需要掌握多项技能，他所需要的知识面会很广，需要过程更需要时间的学习和磨练。
2. 人员开发效率低下。一个产品往往需要多个部门的合作，各部门沟通的有效性直接会影响到产品的质量和产品的进度。如果技术开发人员没有良好的交流沟通能力，可能会严重阻碍项目的推动。尤其是小型的团队开发中，缺乏沟通往往会导致成员对任务内容、要求和职责理解有误，导致开发效率低下，甚至引发成员间的矛盾。开发人员如果不能清楚地表达工作计划、遇到的困难、需要什么支持，会导致项目负责人无法及时掌握项目进展情况，并进行合理分配资源。在工作中时常会发生别人（通常是上级）征询意见时不知如何表达，但被分配具体工作后又觉得自己未被尊重，从而产生挫折感。技术开人员大多思维能力强于交流沟通能力，性格也大多趋向于内向，喜欢做事多于说话。如何提高自身沟通交流能力是摆在很多开发人员面前的一大难题。
3. 技术架构不统一没有延续性。作为设计师，需要保证产品功能的现实，产品功能的可持续性，产品的稳定性及产品的可用性等。产品的这些需求都依赖于架构师对产品技术的规划。架构师在接到商业需求之后，最主要的工作就是将其转化为技术需求。这个过程的完成与架构师抽象思维的能力密不可分。好比说Tiny框架这个项目，主架构师第一个闪过的念头多半就是：这个系统必须具有长期的统一性。而负责每一个Tiny框架功能的架构师，又需要对这些部分进行进一步的抽象化。这些往往是中小企业团队所不具备的。由于缺乏优秀的架构师，导致团队在产品的现实规划上没有自己明确的目标和具体的可行性实施方案，缺乏统一的延续性，导致后期难以满足产品在升级、改版方面的需要。
4. 性能不能满足运营要求。整天只知道大谈“云计算，SaaS”这些东西的团队，注定开发不出优秀的产品。这种毛病在新的开发团队非常常见，因为这可以忽悠更多的客户。不过，新的技术虽好，程序员接受和再培训还需要时间，还要考虑到系统的兼容性问题。因此，夸夸其谈的名词专家，往往死得更惨。尤其是出现大并发的数据考验时，做出来的产品往往会难以满足运营要求。
5. 构建开发框架成本太高无法承受。时下各种软件系统发展越来越复杂，尤其是框架软件，其涉及的问题以及知识面太多。当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等……在遇到这些问题时，开发成本往往会正比例飞速增长，甚至让中小企业团队无法支撑。
想要减少开发工作量或是缩短时间，降低成本，使用框架便是一个很好的选择。尤其是，使用质量好且有延续性的开源框架正在成为主流！
1. 节省团队时间和精力。框架节省了我们不少的时间，并且让扩展变得更容易。由于拥有完整的生态体系，以及活跃的社区氛围，使得团队战斗力更强！由于框架强制使用公共的约定，因此它能有效地解决一些共有的问题。框架能够让工作更连贯，也能避免我们写一大堆自定义模块来实现某些性能，我们所需要做的，就是将这些共用模块放在框架中实现。以Tiny框架为例，一年的开发就需要提交数千个Commits，解决了无数个疑难杂症。此外，从文档维护的角度来看，一年900多页的文档内容，也能够帮助开发团队解决许多难题。
2. 技术支撑更有保障。优秀的开源框架，通常具有高内聚、低耦合、高质量的代码，专职的团队，可以保持项目持续不断的前进。还是以Tiny框架为例，Tiny主工程共有621个Issues，里面有需求，和改进，有BUG。由于有良好知识积累体系，使得使用Tiny框架的人们越用越强，越用越爽！相当于有一个强大的后援团队在为你的项目服务。这些优点，不胜枚举。当A君在青岛的海边悠闲地喝着咖啡时，完全不用担心客户的跟踪电话了。
3. 成本更低，附加值更高。在优秀的开源框架体系里，由于顶层设计避免了重复劳动，所有软件参与者都会避免做重复的事情。尤其是对于个体或小型企业，很明确，光是SSH/I已经不足让你的方案看起来高大上，也不足以支持业务数据量比较大的时候的应用场景，也不足以支撑居高不下的软件开发实施成本。在优秀的开源框架开发团队里，整个团队配置往往更加合理，高低水平者各司其职，使得运营成本更低、附加值也更高。以Tiny为例，正在构建的Tiny生态圈，上百个UI组件及流程组件已经足够你日常使用，还会有更多被不断加入，这些完全就是超值服务了！
总之，使用质量好有延续性的开源框架，基于开源框架做应用是未来中小型软件公司的发展趋势，你将获得更加超值的回报！
欢迎访问开源技术社区：http://bbs.tinygroup.org。本例涉及的代码和框架资料，将会在社区分享。《开源框架那点事儿》成员QQ群：228977971，让我们一起动手，了解开源框架的奥秘！
原文地址：http://j2eetop.blog.51cto.com/10319886/1662021
