导读：开源框架是当前的一个热门话题。国内对开源的认识，也在由拿来免费用的初级理解向更高级别的层次发展。在面对或不的框架时，我们自然会慎重考虑一个话题：借船出海还是造船出海？

架构开发与应用困境

在我的周边朋友身边就发生过这样的事情：

故事1：A君在北京从事Java开发好多年了，萌发了创业的念头，想组建一个开发团队想大干一场。但是慢慢发现，构建一个有战斗力的团队真不容易。后来技术团队的组建初步有了起色，但是技术路线却非常难成一致意见。折腾来折腾去，把有点上道的技术人员都折腾得跳槽了。费了巨高的成本搞了一个架构师，就是利用SSH框架搭建了一个开发环境，数据量小，业务初期还是不错的，但是当业务快速增长的时候，运行速度就无法满足需要了。是重新来过还是在SSH的基础上继续折腾，非常难以抉择！

故事2：Jenny从英国回青岛大半年了，很喜欢青岛这座海滨城市，空气很好，周围的一草一木也很亲切，这也是当初为什么回来的原因之一。不过，Jenny一直在为产品管理的事情焦头烂额。除了开发成本高，软件层次一直比较低。产品团队管理之外，还要考虑技能水平、分工、角色岗位、薪酬、性格特点等等，各方面都耗费了大量的时间。由于缺乏大规模的压力测试，花了大量时间做出来的产品，却不能适应海量数据下的大并发访问。想找一些高手吧，在软件业本来就不发达的二线城市又不太现实；离开二级城市转到一级城市发展吧，又承担不起高额的运营成本与人力资源成本，路在何方真的是个问题！

故事3：经过大半年的筹备，阿灿的技术团队终于组建起来了。不过，人员流动始终是个挥之不去的话题。换了人，技术方案就要换，随之而来的维护问题也是让人焦头烂额！阿灿沮丧了，他怎么也想不明白，为什么新来的人就不愿意继续在老人留下来的系统上进行维护和再开发呢？如何才能建得起来铁大的营盘？

类似的故事，不胜枚举。

顺势而为与借力

总结上述现象，我们往往会发现有以下几个方面的问题。

人员培养速度缓慢。从人力资源团队的角度来讲，更多考虑人员的职业道德是否符合企业文化和价值观。而软件开发项目经理更多考虑的是，新成员是否能够为软件开发项目做出贡献，并符合项目文化和价值观。如果你的软件开发团队都不是自己亲手组建起来的，你又如何能够保证软件开发团队能够按你期望的模式运作？应聘人员通过各种认证，仅仅代表具备了基本的知识体系和理论基础。但任何认证都无法真正体现出每个人的学习能力和应用知识的能力，而这两点恰恰是软件开发项目关心的技能。尤其是，要成为一个的软件架构师，往往需要具备10年以上的软件开发经验，入门的门槛是相当高的，尤其是在互联网产品愈发重要的当下，一个软件架构师往往需要掌握多项技能，他所需要的知识面会很广，需要过程更需要时间的学习和磨练。

人员开发效率低下。一个产品往往需要多个部门的合作，各部门沟通的有效性直接会影响到产品的质量和产品的进度。如果技术开发人员没有良好的交流沟通能力，可能会严重阻碍项目的推动。尤其是在小型的开发团队中，缺乏沟通往往会导致成员对任务内容、要求和职责理解有误，导致开发效率低下，甚至引发成员间的矛盾。开发人员如果不能清楚地表达工作计划、遇到的困难、需要什么支持，会导致项目负责人无法及时掌握项目进展情况，并进行合理分配资源。在工作中时常会发生别人（通常是上级）征询意见时不知如何表达，但被分配具体工作后又觉得自己未被尊重，从而产生挫折感。技术开人员大多思维能力强于交流沟通能力，性格也大多趋向于内向，喜欢做事多于说话。如何提高自身沟通交流能力是摆在很多开发人员面前的一大难题。

技术架构不统一没有延续性。作为设计师，需要保证产品功能的现实，产品功能的可持续性，产品的稳定性及产品的可用性等。产品的这些需求都依赖于架构师对产品技术的规划。架构师在接到商业需求之后，主要的工作就是将其转化为技术需求。这个过程的完成与架构师抽象思维的能力密不可分。好比说Tiny框架这个项目，主架构师个闪过的念头多半就是：这个系统必须具有长期的统一性。而负责每一个Tiny框架功能的架构师，又需要对这些部分进行进一步的抽象化。这些往往是中小企业团队所不具备的。由于缺乏的架构师，导致团队在产品的现实规划上没有自己明确的目标和具体的可行性实施方案，缺乏统一的延续性，导致后期难以满足产品在升级、改版方面的需要。

性能不能满足运营要求。整天只知道大谈“云计算，SaaS”这些东西的团队，注定开发不出的产品。这种毛病在新的开发团队非常常见，因为这可以忽悠更多的客户。不过，新的技术虽好，程序员接受和再培训还需要时间，还要考虑到系统的兼容性问题。因此，夸夸其谈的名词专家，往往死得更惨。尤其是出现大并发的数据考验时，做出来的产品往往会难以满足运营要求。

构建开发框架成本太高无法承受。时下各种软件系统发展越来越复杂，尤其是框架软件，其涉及的问题以及知识面太多。当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整地描述应用的架构关系。接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等……。在遇到这些问题时，开发成本往往会正比例飞速增长，甚至让中小企业团队无法支撑。

开源框架的“借力”与“顺势”

三国时期，曹操率大军想要征服东吴，孙权、刘备联合抗曹，“草船借箭”即来源于此。我们来看看这个故事的几个关键环节。为了快速实施方案，诸葛亮首先找到鲁肃。诸葛亮说：“这件事要请你帮我的忙。希望你能借给我20只船，每只船上30个军士，船要用青布慢子遮起来，还要一千多个草把子，排在船两边。”这就是一种详细的布置说明。接下来是诸葛亮对场景的选择。第三天四更时候，江上大雾迷漫，诸葛亮邀请鲁肃一起靠近曹军水寨时，诸葛亮命船一字儿摆开，叫士兵擂鼓呐喊。曹操以为对方来进攻，又因雾大怕中埋伏，就派六千名弓箭手朝江中放箭。十万支箭很快到手，顺利完成任务！

从这个借箭的故事，我们也会有不少启发。试想，如果诸葛亮循规蹈矩，自己召集人马、突击建造船只，别说借箭，浩大的造船声势肯定马上会被曹操知晓，也就更谈不上借箭了。情况只会变得更加复杂！作为中小软件企业和开发团队，想要减少开发工作量或是缩短时间，降低成本，使用框架便是一个很好的选择。

当然，在借力的过程中，衡量选择一个开源框架，往往有这些考量因素。

清晰、简单易用的代码库。代码复用是把一个功能写成一个模块，以便当再次需要相同功能的时候，可以直接使用，而不用重新开发。举个例子，假如网站需要验证码，你就可以把验证码这个功能单独提取出来以便复用。通常代码复用是通过类与对象来实现的，这也是面向对象编程与面向过程编程主要的区别之一。以响应式网页设计为例，实现起来并不困难，但是要让它在所有的目标设备上都正常运作会有一点小棘手。而框架可以让这一工作变得简单。利用框架，你可以花少的力气创建响应式且符合标准的网站，一切都很简单并且具有一致性。还有很多好处是显而易见的，比如说简单快速，以及在不同的设备之间的一致性等等。也就是说，框架大的“势”就是简单易用，即使只掌握少量的Web知识，你也可以毫无障碍地使用它们。

粉丝使用过程中不断提需求，通过倒推的力量促进创新体系正向循环。不管是在哪里的开源托管网站里，有一些项目确实水准不高，确实是在做重复的劳动，甚至在初始阶段，确实没有什么新意。但是实际上，这些开源作者正是在摸索实践的过程中，了解了有哪些好或不好的东西，在这个过程中锻炼了实战经验，提升了战斗力，为下一轮的产品创新奠定了更好的基础。作为一种开源力量，粉丝反过来施加优化的压力，未尝不是一种正向力量！坚实的社区基础和积累，以及丰富的模板系统，往往可以为框架树立良好的口碑，形成一种“引力场”。尤其是需要有大量忠实的社区粉丝，也是框架实力的好支持。作为社区网站，也要站在运营者角度和用户角度双方面来考虑上诸多问题。比如，在进行Java开源框架的实施过程中，Tiny帮助团队（http://help.tinygroup.org）通过开源社区，在方法论、设计理念、开发体系、设计原则、生态圈、模块化、热部署、水平扩展、元数据等非功能性要求方面，进一步满足用户的需求。在用户角度上完善网站产品，去满足用户的核心需求，帮助用户解决问题。

简单的学习曲线，与相关应用集成更加容易。学习曲线的定义为“在一定时间内获得的技能或知识的速率”，又称练习曲线（practice curves）。人们为了知道学习进程中的现象和进步快慢的详情，作为以后努力的指针，应用统计图的方法作一条线，把它表示出来。它源于“二战”时期的飞机工业，当产量上升时，生产每架飞机的劳动时间会极大地下降。随后的研究表明，在许多行业都存在这种现象。同样，在框架应用中，我们需要的不仅仅是模板，还更想要陈述式的可重用的模板框架。尤其需要能够创建可扩展的互联网应用。

详细的依赖说明，清晰的文档支持与引导系统。写文档不容易，同时也是需要花费一些时间的。作为潜在的用户，我们次接触开源项目，很可能就是通过阅读README文件。我们需要确保它很棒并且包含了有用的信息。以开源框架的开发为例，Tiny团队始终认为文档是能为用户做的好的事了！Tiny框架开源以来，许多团队或企业也在使用Tiny开发自己的应用，在应用过程中提出了许多好的意见、建议、需求，有的甚至直接帮我们提交了Pull Request。正是在这种文档支持与引导的过程中，参与开源的氛围越来越好，Tiny的社区环境越来越完整。这也是我们愿意和大家分享的一个地方。

向后兼容，同时把握大势，对主流技术发展有一个准确的判断。关于软件开发一件很令人生气的事，就是当你升级一个库但是数百个测试失败了。更让我生气的就是我还要重写一半的基础代码，因为有人在没有任何警告的前提下决定打破公共的API。因此，向前看齐，同时致力于维护向后兼容性，也是需要重点把握的方向。比如，可以经常关注：使用这个项目有几个月了？是否觉得它还是不完整的？是否希望API在下一个版本会彻底地修改？是否在要求多并且很老的项目中也能稳定安全地使用？当考虑到向后兼容时，也能有一个很好的跟踪记录。

使用质量好有延续性的开源框架，基于开源框架做应用是未来中小型软件公司的发展趋势。在的开源框架体系里，由于顶层设计避免了重复劳动，所有软件参与者都会避免做重复的事情。尤其是对于个体或小型企业，很明确，光是SSH/I已经不足让你的方案看起来高大上，也不足以支持业务数据量比较大的时候的应用场景，也不足以支撑居高不下的软件开发实施成本。在的开源框架开发团队里，整个团队配置往往更加合理，高低水平者各司其职，使得运营成本更低、附加值也更高。从本质上讲，这也是一种造船服务。不管是学习者、参与者、交流者、使用者，都有自己的收获，在这个过程中，开源团队也会受益匪浅，对开源这两个字也有更深入的理解。

总之，清晰的依赖性和安装说明，一个简要清晰的文档指南，及时的修改日志和仓库的标签，详细的支持语言、运行时、工具版本信息和项目的成熟度，一个可以让用户提问和交流的开源社区，可以让你在使用开源框架的过程中，更加得心应手。郑和下西洋，没有人关心他使用的是什么船；诸葛亮借箭，也没有人关心他使用的是谁的船。不过，他们善于运筹帷幄，很轻松地完成了自己的目的。造船下海，还是借船下海，关键还是在于顺势而为，把握大势！