专访Tiny框架创始人悠然：好的软件设计是“品”出来的

Tiny是基于Java开发的一款开源框架，主要技术领域为J2EE及应用开发平台领域。日前，笔者采访了Tiny开源框架创始人悠然（罗果）请他分享Tiny的构建之路以及对开源的解读。在他看来，好的软件设计是“品”出来的，信奉好的软件架构一定是简单的。

Tiny开源框架创始人 悠然

CSDN：和大家认识一下，介绍一下你的技术背景、目前所负责的领域。

悠然：大家好！我是悠然，Tiny（官网）开源框架创始人，主要技术领域为J2EE及应用开发平台领域，涉猎广泛，在模块化、元数据、模板引擎、数据库分区分表、SOA等等领域等都有较深入实践，吃过N多的亏，上过N多的当，当然也积累了N多的经验。在业余时间也热心于参与开源软件相关工作，在进行软件开源的同时，也编写了大量的技术博客，从问题、原理、实践进行了深入浅出的讲解。我比较欣赏的是：好的软件设计是“品”出来的。我信奉，好的软件架构一定是简单的。

CSDN：你们的团队架构是怎样的？如何分工？

悠然：TinyFramework的开发团队是由稳定的团队成员组成的。我也尝试过招募一些愿意参与的爱好者，实际执行效果不太好，当然原因也是各方面的，我也非常理解没有坚持下来的参与者。

团队架构与分工。对于成功的开源团队而言，个人强大的技术是一方面，但团队力量远大于一群人的简单相加。我们项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成，每位成员在自己专业领域内发挥主导作用，并可以为项目的成功提出非自己领域内的建议。最终的项目成果是各位专业人士共同努力的结果，所有人对最终成功承担同等的责任。就像竹子“千磨万击还坚劲”的精神一样，每个项目成员都有当家做主的机会，应相信自己在本领域内是专家，在我的专业范围内，我可以说了算！Tiny团队就是这样，我们每个团队成员的自主精神贯穿在日常的工作始终。

团队成员的沟通方式主要有如下几种：（1）聚众吃饭：基本上一年当中，聚众吃饭的次数得有20多次。吃饭的理由千奇百怪了，家里添丁要请、技术晋级要请、获奖了请等等，当然最多的请客理由还是由于出现严重BUG、有严重的设计缺陷、提交了影响开发的代码等等技术相关的理由，边吃边聊边打闹，同时就提升了大家的能力，同时也让大家认识到这种类型的错误，会导致请客吃饭的后果，下次自然是坚决不犯了。（2）社区公开课。我们通过论坛（http://bbs.tinygroup.org）定期进行公开课交流。一般是每周四晚上八点。通过交流，我们也建立了非常好的互动效果。（3）GIT中的Issues：团队有句口头禅，嘴巴讲的不算。所以不管是需求还是BUG，都要统统录到Issues当中，于是提出问题、批注问题、解决问题、跟踪问题、关闭问题，都在Issues当中进行管理。当然，所有的过程也就成为呈堂证供，抵赖不得。不论是线上还是线下的交流，对于我们的团队协作与和谐都起了非常大的作用，互为补充。

开源Tiny是对自己思想的验证

CSDN：开源往往需要很大的勇气。我们注意到，Tiny推出之后，在开源网站上高居Java类前几名。为什么要想到开源Tiny Framework？

悠然：其实在开发TinyFramework之前，也在公司的体制下主导了开发平台的开发，但是由于在公司体制下，需要完全按照公司的要求和规范来开发，实际上就是要做许许多多的妥协，而这些妥协可能会对一个框架产生比较严重的伤害。而我期望做一个各方面比较均衡的开发平台，于是就从各种小的专题性验证开始，比如：流程化编程、模块化设计、数据库分区分表等等一一进行验证，当验证的范围越来越大，涵盖的领域越来越多的时候，才真正开始决定做一个开源框架。因此，追本溯源，最初的初衷就是对自己思想的一些验证而已。

CSDN：很好奇，Tiny团队是如何运作的？是什么鼓舞你们从事开源工作？

悠然：在早期，我们还是默默无闻的，因为我们不想在框架还是一个半成品的时候就拿出来，直到我们已经开发完毕并且在自己的项目中进行了充分验证的时候才真正的在社区或相关网站进行露面。我们大致是从以下几个角度维护项目和社区的：

1. 代码托管在Git仓库。目前有360 watches，588 stars，451 forks，相对于它仅仅托管到Git仓库一年的时间，数据还不错。
2. 构建Tiny文档WiKi。Tiny文档总共有900多页，涵盖了设计、实现、示例、实践等方方面面，目前月访问量在4万PV左右。
3. 创建Tiny论坛社区。Tiny论坛是新推出的专注入Tiny方面的交流与沟通平台，目前论坛已有注册用户1000多人，包括：有问必答、开源公开课、精彩文摘、实战分享等栏目。尤其是社区的“有问必答”栏目，对于产品的改进与完善，发挥了十分重要的作用，目前吸引了不少专业人士及Tiny爱好者加入。
4. 创建Tiny交流QQ群：228977971。由于采取了比较严格的管理方式，所以是对技术纯洁性保持非常良好的群。目前已超过1000多人，并在不断增长。

通过上面的一些与项目相关的社区、博客、QQ群等形式与广大Java框架、Tiny爱好者进行了充分的互动与交流。不管是学习者、参与者、交流者、使用者，都有自己的收获，在这个过程中，我们也受益匪浅，对开源这两个字也有了更深入的理解。

开源呈现螺旋式发展

CSDN：如何理解国内开源生态链？在2年多的开源实战中，印象最深的事情是什么？

悠然：实际上，开源这事儿也是一个螺旋式发展的代表，好几年差几年。整体来看，国内对开源的认识也在由拿来免费用的初级理解向更高级别的层次发展。从整体来看，国人开源的技术和产品相对还处在一个初级阶段，比如：仅仅是把代码开放出来，没有后续的社区建设，也没有形成生态圈等等各种问题。但是由于国内的开源产品基数太大，我们可以看到越来越多的优秀开源者和优秀开源产品涌现出来，这也符合量变引起质变的客观规律。

TinyFramework的立意是企业级的开发平台，因此在方法论、设计理念、开发体系、设计原则、生态圈、模块化、热部署、水平扩展、元数据等非功能性要求方面做了大量的探索和实践，当然在这些领域也都有了相当不错或者可以接受的解。我们相信，只要能切实践行我们团队的格言“Think big，start small，scale fast！”，我们就一定会成功、领先的开源产品之一。

在我们进行实践的过程中，也会碰到一些人的不理解或者说是非议吧，有时候直接就在我们的软件、博文下面回复“轮子”或者“然并卵”什么的。我是这样看待这个问题的，不管是在哪里的开源托管网站里，确实有一些项目确实水准不高，在初始阶段，确实没有什么新意，确实是在做重复的事情。但是实际上这些重复的意义在于：这些开源作者正是在做轮子的过程中，了解了如何做轮子，做轮子过程中有哪些坑，有哪些好或不好的东西，在这个过程中锻炼了实战经验，提升了战斗力，为下一轮的创新或做出不是轮子的产品奠定了更好的基础。开源作者们既使现在做的是你们看起来的“轮子”或者“然无卵”的事情，但是在量变的过程中，终将会产生质变。华丽丽的完成蜕变的过程。就是最终开源作品没有蜕变成高大上的产品，开源者在这个过程中也会得到洗礼，得到技术的提升能力的提高。

CSDN：你认为TinyFramework最突出的优点是什么？能否介绍一下你们的新开源实践，比如模板语言，分库分表，等等。

悠然：TinyFramework的优点很多，主要有以下几个方面：

首先，设计理念决定了设计的目标。

（1）使用灵活：可以整个使用它，也可以只用它的一个或几个部分。Tiny构建者认为，一个完整的框架可能需要有许许多多个部分组成，但是对于实际应用的用户来说，它可能只需要其中的一部分功能。构架一定要有这种能力，可以由使用者进行点菜式，使用，避免只要用一点点功能，就要引入许许多多的内容。

（2）学习成本低、上手容易：框架的学习成本必须非常低，这样才可以让使用者更容易上手，避免由于学习难度大而导致的学习曲线太陡、太长。

（3）保持核心的稳定性：Tiny框架是立足于在需要稳定、安全要求非常高的应用环境中使用的，因此其稳定性就是框架构建者首要思考目标，核心部分只使用经过充验证及广泛应用的第三方包。

（4）资产的可积累性：只有易于知识积累，才可以真正做到越用越强。

其次，设计原则解决目标冲突时的解决策略。

（1）约定优于配置原则-COC。

（2）不要重复你自己原则-DRY。

（3）减法原则 ：减法原则是我们自己提出的，意思就是给程序员做减法。

（4）模块化原则：模块化对于软件开发过程中开发、高度、集成、发布、维护过程中所起的作用及节省或花费的巨大成本。因此提出了Business Unit的概念，使得与模块相关的所有内容都可以放在一起。

（5）自动组装原则：在整个Tiny框架的构建过程中，都非常注重集成过程的自动组装，要求做到扔进去不用管，由框架自动集成。

（6）下级服从上级原则：Tiny框架则从框架层级做了限制，使得下级必须服务上级。

（7）单一原则：通过单一原则进行强制性的约束，使得一个模块只解决单一模块应该解决的问题，从而避免不同的问题放在一起解决所导致的胡子眉毛缕不清的问题，同时也避免了不恰当的依赖及模板引用。

（8）集中配置原则：在Tiny框架我们对配置做了大量的工作，一个是COC方式，如果不配，则采用系统默认的值；一个是集中原则：把需要人工需要配置的内容都集中起来统一配置；一个是对于不需要人工干预的配置，那就集成在Jar包中，作为发布者发布项的一部分。

再就是，一些创新性的技术应用。

（1）SOA：Tiny的服务是一次开发到处使用的，也就是一旦完成了服务的开发，你可以用RMI，WebService,Json,Xml等等，各种你想到想不到的方式进行服务调用。

（2）服务水平扩展能力：在遵守Tiny开发规范的前提下，可以方便的进行接入和服务层的水平扩展。也就是说如果你的处理能力不足的时候，只要加一台机器就可以增加处理能力，而不必对现有运行的环境进行任何变化。

（3）模块化技术：Tiny的模块化的设计思想是没有什么不能进行模块化，也就是说所有的文件都可以放在Jar包中。为此我们做了大量的研究与实践，做到了所有的文件都可以放入到Jar包中，甚至连Jsp也可以放入Jar包。通过模块化技术，可以方便的进行模块分隔与复用。

（4）自组装技术：Tiny的自组装设计思想是所有的模块都可以做到加入即可用，去除就消失。也就是说，如果你用别人的一个组件，你只要通过Maven依赖它即可以；如果你不想用了，取消Maven依赖即可。这样就会大大减少集成相关的工作量。

（5）热部署技术：关于热部署的实践，这个有许多种，比如OSGI等等，但是不管哪一种，都有一定的强依赖性，或者说是侵入性。Tiny的热部署实现机制则简单的多，只要按照正常的方式来开发Jar包，并且配置一个Bundle声明文件即可。实际应用当中，即可以按照Bundle机制运行，也可以按照普通Jar包来运行。

（6）UIML技术：UIML也就是统一界面描述语言的意思。通过这一特性，再加上配套的可视化界面设计工具，就可以实现一次开发到处使用的界面开发目标。

（7）AOP缓冲框架：可以有效剥离缓冲与业务代码，可以透明的切换缓冲方案切换，可以大幅降低缓冲相关代码编写的开发与重构成本。

（8）文档生成框架：凡是按照Tiny开发规范进行开发，许多的文档都可以通过工具自动化生成，文档与代码不一致不再是一个问题，同时还可以节省大量的文档编写时间。

本来是没有自己写一个模板引擎的计划的，因为按我的理解，一直认为这种“语言”级的引擎，难度是非常大的。总感觉自己的水平不够，因此不敢有这个念头。直到大量使用Velocty的时候，碰到Velocty诸多不尽如人意的地方，但是又无能为力，退回到JSP吧，又心不有甘。于是就期望着寻找一种语法结构接近Velocty，但是又没有Velocity这些不方便之处的模板语言。但是实际上一圈找下来，并没有找到满足自己期望的模板语言，于是就萌生了写一个模板语言的想法。当然，过程中也经历了诸多折腾，但是目前已经是相当有竞争力的模板语言，概括的介绍一下：

Tiny模板语言是一个基于Java技术构建的模板引擎，它具有体量小、性能高和扩展易的特点。 适合于所有通过文本模板生成文本类型内容的场景，如：XML、源文件、HTML等等，可以说，它的出现就是为了替换Velocity模板语言而来，因此在指令集上在尽量与Velocity接近的同时，又扩展了一些Velocity不能很好解决问题的指令与功能，在表达多方面则尽量与java保持一致，所以非常的易学易用。

• 体量小：表现在总共5000+行的代码，去掉一些扩展功能，核心引擎只有不行3000行代码
• 性能高：表现在与现在国内几款高性能模板语言如：HTTL、Jetbrick、webit等引擎的性能相比，近乎伯仲之间，但是比Velocity、Freemarker等则有长足的进步，效率大致是Velocity四倍
• 扩展性高：表现在Tiny模板语言在所有组成部分都可以自行扩展
• 易学习：表现在Tiny模板语言概念清晰、语言组织方式采用了现有流行度非常高的Velocity语法体系，有相关经验的人可以快速上手。
• 使用方式灵活：表现在，可以单例方式、多例方式，并可以与Spring等有良好集成
• 功能特点介绍
• 类似于 Velocity 的指令方式，相同或相似指令达80%左右
• 支持可变参数方法调用
• 支持类型成员方法重载
• 支持函数扩展
• 采用弱类型方式，对于模板层的代码编写约束更小，模型层怎样变化，模板层的代码调整都非常容易
• 支持宏定义 #macro
• 支持布局 Layout
• 支持宏嵌套调用
• 强大的开发工具支持Eclipse插件方式
• HTML代码渲染支持

其实在开发TinyDbRouter之前，我们主要是想找一个比较合适的数据库分区、分表方案，为此也学习了各种实现方案，但是总是在功能性、可控性等方面不能得满足，评估下来之后，还是决定自己尝试写一下，当然写完之后感觉还是非常不错的，经过一段时间的验证、测试、实际应用，在各方面都有非常不错的反应，因此才有现在开源的TinyDbRouter。

• 水平扩展
• Tiny DB Router是一种数据库水平扩展解决方案
• 支持JDBC 3及JDBC 4
• 使用限制
• 不支持物理跨库关联(Join)查询
• 分表时只支持游标分页，不支持SQL分页
• 分表规则字段不允许修改
• 设计目标
• 支持各种常见数据库
• 分布式主键生成器
• 自增长主键完美支持
• 支持SQL92规范中除使用限制之外的绝大多数SQL语句
• 在性能方面最大程度接近原生数据库系统
• 能完美支持统计、排序
• 支持读写分离，支持权重负载均衡方案
• 集群事务统一
• 读写分离
• 单库分表
• 多库分表
• 良好的扩展能力（分区规则扩展、分表规则扩展、主键生成扩展）

整体来说，是非常不错的数据库分库分表方案，当然了，它也存在一些不足，它的实际应用目前还是在我们自己的项目当中，还需要进行充分的应用实践去锤炼。

当然，这两个子项目只是Tiny框架中的比较有代表性的子项目，实际上Tiny框架中有非常多的优秀子项目，希望大家能多多了解Tiny，自己发掘其中的内容。

CSDN：TinyFramework的应用案例有哪些？目前已经开放了哪些应用？可以和我们分享下吗？

悠然：TinyFramework从初版出来，目前主要在我们自己的公司进行推广和应用。目前已经有许多企业级和互联网级产品基于Tiny开发，并在几十家客户中使用。Tiny框架开源以来，许多团队或企业也在使用Tiny开发自己的应用，在应用过程中提出了许多好的意见、建议、需求，有的甚至直接帮我们提交了Pull Request。一年来，Tiny的社区环境越来越完整。在2015年Tiny的外部用户数上将会有一个较大的提升。

在功能性需求方面，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(集成开发工具)：提供了可视化界面设计，可视化流程编排、模板引擎编辑器、代码生成器，服务编辑器、元数据编辑器、数据库设计器。

还有许多许多的内容，欢迎大家到我们的官网查阅相关内容。

CSDN：为何你会说：“好的软件设计是“品”出来的，信奉好的软件架构一定是简单的”。这句话怎么理解？在你看来好的软件应具备哪些条件？

悠然：在软件实践中，对于一个特定的问题，不会是有一个唯一的最好的解决方案的。因为我们在软件实践过程中，不仅仅要考虑功能性问题，还要考虑非功能性问题，比如：安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性等等，更要命的是，这些非功能特性有些是矛盾的，存在此消彼涨的情况。这个时候，每种方案的选择都会影响到这些非功能指标，这个时候，作为一个技术决策者，就要对左边走还是右边走，进行仔细的斟酌，也就是我说的“品”，只有把每种方案都“品”到位了，才可以真正选择出真正符合自己要求的解决方案。

我经常说：软件能不能做好，要看你是不是能把一个软件分解得粒度足够小。当你能把一个复杂的问题分解成非常单一的小问题的时候，这个时候你就一定可以有相当不错的解决方案。因为针对每一个小问题，我相信只要水平不是太差的，都可以给出完美的解或者相当不错的解，当我们把所有的小问题都能给出完美的解或者相当不错的解，甚至是可以接受的解的时候，最初的大问题也就可以有完美的解或者相当不错的解。而一个简单的小问题，它的软件架构一定是简单的，而这些简单架构的累加，由于是高内聚、低耦合的，那么整个软件架构也可以认为是简单的。这也是我们的框架采用“Tiny”这个名字的原因之一。

CSDN：未来的下一步计划是什么？

悠然：Tiny框架从诞生至今，不管是从框架规模、实际应用都已经取得了相当的成绩，当然也存在一些问题，接下来我们将会在以下方面进行完善：

• 文档完善：目前我们的文档已经有近千页，但是文档的质量还有待提高，接下来要对文档质量在条理性、有效性、针对性方面作重点提升
• 实例完善：目前我们已经有了一些简单的示例，但是还缺少重量级的实例，这方面会做一些即能体现Tiny特性，又有实际应用价值的开源产品。（剧透一下：目前我们正在基于Tiny开发一个项目管理软件，到时依然会开源发布）
• 视频讲解：对于内部客户来说，我们通过培训可以解决一些文档和实例不足的问题，但是对于外部用户来说由于缺少培训，实例也相对简单，导致客户上手稍慢。为此我们准备录制视频讲解课件，方便用户上手。
• 功能扩展：后面我们会重点对互联网应用方面的一些技术及功能进行功能扩展。
• 组件库：由于Tiny框架实际上一个面向组件的开发框架，我们自己做了许多的组件，这些组件可以大大提升软件的开发效率及软件的成熟度。组件库的构建对于构建Tiny框架生态圈是非常重要的。

CSDN：有什么话和CSDN网友分享，一起进步？

悠然：CSDN是一个非常优秀的程序员社区，同时也有自己的代码托管及开源版块，并且也吸引了大量的开源作者入驻。在这里，我把开源过程中的一些感触和大家分享一下，不一定正确，大家一起探讨。

关于收入的问题，如果期望开源能够快速给自己带来收入，这个可能绝大多数的可能是会失望的。一般来说，一个开源产品，从开始、发展，到能有收入，能营收平衡，这个一个漫长及艰难的过程。如果靠这个买米买肉，估计要饿死的。问题来了，如果做开源不关心收入，为什么还要开源呢？我可想可能有如下可能：

获取精神上的满足。比如，你做了一个好东西，但是又卖不了钱，放在自己兜兜里，一点成就感也没有，拿出来开源，让大家使用使用，自己获得一下成就感，也是满不错的。

获取社会的认可。通过开源，获得相当的社会认可度，有可能东方不亮西方亮，获得更好的发展机会或工作机会，或者获得与别人合作的机会。

收集需求。一个人在那里做，总是有这样那样局限的，即使你是超级牛人，通过给别人免费使用，别人给你提出这样那样的意见和建议，可以帮你快速丰富和完善产品。

用户测试。有时候，你做了个东东，自己也不知道到底好不好，现在有许多用户来使用，实际上也同时给你做了测试。

获取用户群。有时候，一个产品放在那里没有什么价值，但是随着用户群越来越大，可能就可以有盈利的潜质了。同时也是潜在用户的一种培育，免费使用的人多了，可能就有愿意掏钱获得更好的服务与产品或者定制开发的人了。

一种市场营销手段。本来产品做也还可以，通过开源，获得市场认可，提高知名度，为后续推广奠定基础；同时让人们看到内部的实现，从黑盒变成白盒，让人们放心的选择。

当然也可能是其中的几个或者全部。总之，开源是一个艰辛的选择，需要长久的坚守，需要不急不燥的一份态度。所以，开源是一种修行，有可能是没有成果的凡人，也可能是小有成就的佛子，也有可能大有成就的尊者，还有可能是至真至高的佛。