【51CTO.com独家特稿】嘉宾介绍
罗果是Tiny开源框架创始人，主要关注技术领域为J2EE及应用开发平台，涉猎广泛。他在模块化、元数据、模板引擎、数据库分区分表、SOA等领域有较深入实践，吃过N多的亏，上过N多的当，当然也积累了N多的经验。
在业余时间，罗果热心于参与开源软件相关工作，在进行软件开源的同时，也编写了大量的技术博客，从问题、原理、实践方面进行了深入浅出的讲解。
他经常挂在嘴边一句话是：好的软件设计是“品”出来的。信奉好的软件架构一定是简单的。
下面是罗果先生回答51CTO小编的几个问题，我们整理出来以飨读者。
1.开发TinyFramework的初衷是什么?
我在开发TinyFramework之前，也在公司的体制下主导了开发平台的开发，但是由于在公司体制下，需要完全按照公司的要求和规范来开发，实际上就要顾及各方面的平衡，而这些平衡可能会对一个框架产生严重的伤害。而我期望做一个各方面比较均衡的开发平台，于是就从各种小的专题性验证开始，比如：流程化编程、模块化设计、数据库分区分表等等一一进行验证，当验证的范围越来越大，涵盖的领域越来越多的时候，才真正开始决定做一个开源框架。
因此，追本溯源，最初的初衷就是对自己思想的一些验证。
2.前段时间TinyFramework刚推出 2.0 版本，新的版本里有哪些新的特性?在一年的开发中，有哪些值得记录的故事?
TinyFramework的立意是企业级的开发平台，因此在方法论、设计理念、开发体系、设计原则、生态圈、模块化、热部署、水平扩展、元数据等非功能性要求方面做了大量的探索和实践。
当然在功能性需求方面，也有非常多的突破，由于Tiny框架涵盖的功能太多，因此只拿几个有代表性的功能来简单介绍一下：
◆TinyDBRouter(数据库分区分表)：基于JDBC层实现，可以支持SQL92规范下的各种数据库进行透明的数据库分区、分表读写分离等水平扩展。
◆TinyTemplate(模板引擎)：一个类 Velocity的模板引擎，但是功能更强大，添加了许多Velocity不支持的特性，运行速率大致是Velocity的4倍。
◆TinySqlDSL(数据库开发框架)：基于领域查询语言方式的数据库开发框架，可以在Java中用类似于写SQL的方式来进行数据库编程，比较好的解决了数据库与Java两层之间结合时的问题(要么两者是分离的如iBatis，要么引入一种全新的语言如Hibernate的HSQL，要么就是在Java中进行大量的SQL拼接)。当然数据库的开发方案有许多种解，各种解有各种解的优缺点，DSL方式也是一种实现方案，有其自己的优缺点。
◆TinyUI(界面引擎)：主要解决WEB应用开发中的模块化和JS、CSS及各种静态资源管理的问题，主要解决静态资源Jar包化、CSS 合并打包压缩、JS合并打包压缩，UI模块之间的依赖关系等体系性问题。
◆TinyStudio(集成开发工具)：提供了可视化界面设计，可视化流程编排、模板引擎编辑器、代码生成器，服务编辑器、元数据编辑器、数据库设计器。
3.你平常是怎样维护TinyFramework项目和社区的?
在早期，我们还是默默无闻的，因为我们不想在框架还是一个半成品的时候就拿出来，直到我们已经开发完毕并且在项目组内进行了充分验证的时候才真正地在社区或相关网站进行发布。我们大致是从以下几个角度维护项目和社区的：
◆代码托管在开源中国的git仓库：https://git.oschina.net/tinyframework/tiny。目前有294 watches，453 stars，361 forks。
◆构建Tiny文档WiKi：http://www.tinygroup.org/confluence/display/TF。Tiny文档总共有900多页，涵盖了设计、实现、示例、实践等各方面，目前日访问量在1500左右。
◆创建Tiny社区：http://bbs.tinygroup.org。Tiny社区是新推出的专注入Tiny方面的交流与沟通平台。
◆创建Tiny交流QQ群：228977971。QQ群采取比较严格的管理方式，对技术纯洁性保持良好。目前该群已有用户1000多人。
通过上面的一些与项目相关的社区、博客、QQ群等形式，我们与广大Java框架、Tiny爱好者进行了充分的互动与交流。不管是学习者、参与者、交流者、使用者，希望大家都有收获。同时，在这个过程中，我们也受益匪浅，对开源项目也有了更深入的理解。
4.TinyFramework有哪些优点和特点?有没有哪些特殊的或者创新的技术运用?
◆设计理念决定了设计的目标
使用灵活：可以整个使用它，也可以只用它的一个或几个部分。Tiny构建者认为，一个完整的框架可能需要由许多个部分组成，但是对于实际应用的用户来说，它可能只需要其中的一部分功能。框架一定要有这种能力，可以由使用者进行菜单式使用，避免只要用一点点功能，就要引入许多其他的功能。
学习成本低、上手容易：框架的学习成本必须非常低，才可以让使用者更容易上手，避免由于学习难度大而导致的学习曲线太陡、太长。
保持核心的稳定性：Tiny框架要求在稳定、安全要求非常高的应用环境中使用，因此其稳定性就是框架构建者首要思考的目标，核心部分只使用经过充分验证及广泛应用的第三方包。
资产的可积累性：只有易于知识积累，才可以真正做到越用越强。
◆设计原则解决目标冲突时的解决策略
约定优于配置原则-COC
不要重复你自己原则-DRY
减法原则 ：减法原则是我们自己提出的，意思就是给程序员做减法。
模块化原则：模块化对于软件开发过程中的开发、高度、集成、发布、维护过程中所起的作用是节省可能要花费的大成本。因此，我们提出了Business Unit的概念，使得与模块相关的所有内容可以放在一块。
自动组装原则：在整个Tiny框架的构建过程中，都非常注重集成过程的自动组装，要求做到用户使用起来不用管，由框架自动集成。
下级服从上级原则：Tiny框架从框架层级做了限制，使得下级必须服务上级。
单一原则：通过单一原则进行强制性的约束，使得一个模块只解决单一模块应该解决的问题，从而避免不同的问题放在一起解决所导致的混合问题，同时也避免了不恰当的依赖及模板引用。
集中配置原则：我们对Tiny框架配置做了大量的工作，一个是COC方式，如果您不进行配置，可以采用系统默认的值;一个是集中原则，把需要人工配置的内容集中起来做统一配置;一个是对不需要人工干预的配置，那就集成在Jar包中，作为发布者发布项的一部分。
#p#
◆一些创新性的技术应用
SOA：Tiny的服务是一次开发到处使用，也就是一旦完成了服务的开发，你可以用RMI，WebService，Json，Xml等等，或者其他你想不到的方式进行服务调用。
服务水平扩展能力：在遵守Tiny开发规范的前提下，可以方便的进行接入和服务层的水平扩展。也就是说当你的处理能力不足的时候，只要加一台机器就可以增加处理能力，而不必对现有运行的环境进行任何变化。
模块化技术：Tiny模块化的设计思想是全部都可以进行模块化，也就是所有的文件都可以放在Jar包中，甚至连Jsp也可以放入Jar包。通过模块化技术，我们可以方便的进行模块分隔与复用。
自组装技术：Tiny的自组装设计思想是所有的模块都可以做到加入即可用，去除就消失。也就是说，如果你用别人的一个组件，你只要通过Maven依赖它即可以;如果你不想用了，取消Maven依赖即可。这样就会大大减少集成相关的工作量。
热部署技术：关于热部署的实践有许多种，比如OSGI，但是不管哪一种，都有一定的强依赖性，或者说是侵入性。Tiny的热部署实现机制则简单的多，只要按照正常的方式来开发Jar包，并且配置一个Bundle声明文件即可。实际应用当中，既可以按照Bundle机制运行，也可以按照普通Jar包来运行。
UIML技术：UIML也就是统一界面描述语言的意思。通过这一特性，再加上配套的可视化界面设计工具，就可以实现一次开发到处使用的界面开发目标。
AOP缓冲框架：可以有效剥离缓冲与业务代码，可以透明的切换缓冲方案，大幅降低缓冲相关代码编写的开发与重构成本。
文档生成框架：按照Tiny开发规范进行开发，许多的文档都可以通过工具自动化生成。文档与代码不一致不再是问题，同时还可以节省大量的文档编写时间。
5.目前TinyFramework使用情况如何?成功的应用案例可以和我们分享下吗?
TinyFramework从初版出来，目前主要在公司内部进行推广和应用。同时，已经有许多企业级和互联网级产品基于Tiny开发，并在几十家客户中使用。产品开源以来，许多团队或者企业在应用过程中提出了许多好的意见、建议和需求，有的甚至直接帮我们提交了Pull Request。一年以来，Tiny的社区环境越来越完善，期望在2015年，TinyFramework能够在外部用户数上有一个较大的提升。
6.能否稍微介绍一下你们的开发团队?你们平时都是怎样进行沟通协作的?
TinyFramework的开发团队由稳定的团队成员组成。我也尝试过招募一些愿意参与的爱好者，实际执行效果不太好，当然原因也是各方面的，我也非常理解没有坚持下来的参与者。
团队成员的沟通方式主要有如下几种：
◆团队建设：上一年当中，大家一块吃饭讨论有20多次。吃饭的理由很多，比如家里添丁、技术晋级、产品获奖等，当然最多的聚餐理由是由于出现严重Bug，或者有严重的设计缺陷、提交了影响开发的代码等技术相关的理由。大家边吃边聊又提升了技术能力，同时也让大家认识到这种类型的错误根由，保障下次不再出现类似问题。
◆GIT中的Issues：团队有句口头禅，嘴巴讲的不算。不管是需求还是Bug，都要录入到Issues当中，由各管理员统一进行协调管理。提出问题、批注问题、解决问题、跟踪问题、关闭问题，都要在Issues当中进行管理。
不论是线上还是线下的交流，对于我们的团队协作与和谐发展都起了非常大的作用，互为补充。
7.你能否谈谈你对开源的理解以及国内开源技术和产品的看法?
这个问题有点大，就拿我以前写的一篇博文中的内容来回答我对开源的理解。
关于收入的问题，如果期望开源能够快速给自己带来收入，绝大多数可能会失望。一般来说，一个开源产品，从开始，到发展，到能盈利，***实现营收平衡，这是一个漫长及艰难的过程。
那开源不关心收入，为什么还要开源呢?我想可能有如下可能：
◆获取精神上的满足
比如，你做了一个好东西，但是前期卖不了钱，放在自己这里，没有太多成就感。如果拿出来开源，让大家可以使用，开发者会获得一些成就感。
◆获得社会的认可
通过开源，获得相当的社会认可度，获得与别人合作的机会，更可能赢得更好的发展或工作机会也说不定。
◆收集需求
一个人在那里做，总是有这样那样的局限。即使你是超级牛人，通过给别人免费使用，别人给你提出各种意见和建议，可以帮你快速丰富和完善产品。
◆用户测试
有时候，你做了个东东，自己也不知道到底好不好，现在有许多用户来使用，实际上在帮你做测试。
◆获取用户群
有时候，一个产品放在那里没有什么价值，但是随着用户群越来越大，可能就有盈利的潜质了。同时也是对潜在用户的培育，免费使用的人多了，可能就有愿意付费获得更好的服务与产品或者定制开发的人了。
◆一种市场营销手段
本来产品本身做的不错，通过开源，获得市场认可，提高知名度，为后续推广奠定基础;同时让人们看到内部的实现，从黑盒变成白盒，让人们放心的选择。
当然也可能是其中的几个或者全部。总之，开源是一个艰辛的选择，需要长久的坚守，需要不急不燥的一份态度。
所以，开源是一种修行，你在这个阶段中，可能是没有成果的凡人，也可能是小有成就的佛子，更有可能是大有成就的尊者，甚至是至真至高的佛。
接下来回答国内开源技术和产品的看法：
实际上，开源项目的发展也是符合螺旋式的轨迹，整体来看，国内对开源的认识也在由拿来免费用的初级理解向更高级别的层次发展。从整体来看，国人开源的技术和产品相对还处在一个初级阶段，比如：仅仅是把代码开放出来，没有后续的社区建设，也没有形成生态圈等各种局限。但是由于国内的开源产品基数大，我们可以看到越来越多的优秀开源者和开源产品涌现出来，这也符合量变引起质变的客观规律。Tiny框架与这些优秀开源产品相比，还比较稚嫩，还有非常大的差距，不过我们相信，只要能切实践行我们团队的格言“Think big, start small, scale fast!”，我们就一定会成为优秀的开源产品之一。
欢迎大家多关注我们的Tiny社区：http://bbs.tinygroup.org。有关Tiny的话题，欢迎加入QQ群：228977971。
