理想的开源框架与设计原则

理想的开源框架

• 她应该是小的、简单的，满足Simple Is Beautiful
• 她应该是成长性好的，随着不断的扩展，她可以越来越丰满
• 她应该是有良好工具支持的，为什么要花时间做工具可以完成的事情呢？
• 她应该是自组装的，也就是尽可能的脱离配置，而是用一种依赖即可用，取消依赖即消失的全自动处理模式
• 她应该是模块化的，所有的内容都可以被打入jar包而作为一个整体进行发布，并且能支持热部署的，可以开着车儿换轮胎的
• 她应该是支持水平部署的，想加服务器就加，想减服务器就减
• 她应该是有良好知识积累体系的，使得使用Tiny框架的人们越用越强，越用越爽
• 她应该是便于企业降低开发成本的，便于技术经理控制开发进度的，便于开发人员快速上手的
• 她应该是避免重复劳动的，所有软件参与者都不应该做重复的事情
• 她应该是自管理的，最好不要让程序员配置这个配置那个
• 她应该是让人有种"众里寻他千百度,蓦然回首,那人却在,灯火阑珊处”的开发框架

按照这个目标去设计

• 虽然整体体量比较大，但是它的每个模块都分得非常小，因此非常容易掌握
• 它的各种组件都可以方便的进行扩展，通过扩展可以不断的提升系统的处理能力
• 它的工具已经非常强大，而且它还是变得更加强大。
• 不管是管理台还是过滤器、Servlet，不管是流程组件还是UI组件，还是UI组件包等等都是可以自组装的
• Web工程只是个集合，除了配置文件和Pom依赖，不应该有其它东西
• 支持水平扩展，同时可以支持7*24小时运行
• 开始团队由金字塔向哑铃型转变，高低水平者各司其职
• 绝大多数情况下，要做的只是依赖，而不需进行配置

这样去打造框架——设计原则梳理

1. COC原则

Tiny框架在设计时充分考虑此原则，凡是可以通过一定的约定来大大减少配置或开发量的，一般都会采用。所以在Tiny框架的扩展、开发、配置过程中，会经常发现一些“潜规则”，如果利用好这些“潜规则”，会起起事半功倍的效果。无标签评论用户图标: cskang蔡少康发表：Convention over Configuration（CoC）–惯例优于配置原则简单点说，就是将一些公认的配置方式和信息作为内部缺省的规则来使用。例如，Hibernate的映射文件，如果约定字段名和类属性一致的话，基本上就可以不要这个配置文件了。你的应用只需要指定不convention的信息即可，从而减少了大量convention而又不得不花时间和精力啰里啰嗦的东西，配置文件很多时候相当的影响开发效率。

Rails 中很少有配置文件（但不是没有，数据库连接就是一个配置文件），Rails 的fans号称期开发效率是 java 开发的 10倍，估计就是这个原因。Maven也使用了CoC原则，当你执行mvn -compile命令的时候，不需要指源文件放在什么地方，而编译以后的class文件放置在什么地方也没有指定，这就是CoC原则。

2. DRY“不要重复自己”原则

Tiny框架的构建者对于做重复的事情一向是深恶痛绝的，因此非常不原意开发人员在基于Tiny框架进行开发时出现重复的内容。为此Tiny框架在设计上做了大量的工作，来避免程序员做违反DRY原则的内容，所以在Tiny框架中，所有的工作内容都是做一次就足够。无标签评论用户图标:cskang蔡少康发表：

DRY——Don't RepeatYourself Principle，直译为“不要重复自己”原则^_^

DRY简而言之，就是不要写重复的代码。原则本身很简单，但是，对于OOAD来说，有着非常重大的意义。

DRY利用的方法就是抽象：把共同的事物抽象出来，把代码抽取到一个地方去。这样就可以避免写重复的代码。

举一个DRY的典型例子，如果在一个类构造的时候，需要进行成员的初始化，在进行了某些操作以后，同样要进行初始化，那么就可以把“初始化”抽象出来，做成一个方法Initial()，在构造和需要用到的地方调用它。

虽然，抽取重复代码是利用DRY的一个好的开端，但DRY的实质是，一个需求，用一个部分来完成。当你试图避免重复代码的时候，实际上，你做的应该是用一段代码来完成一个需求。

为什么要用DRY原则？DRY会给代码维护带来很大的好处。以类的初始化为例，假设类修改了，增加、减少或是修改了成员，如果不写Initial()，那么你可能至少要修改两处，而且，修改之处也可能出现不一致，维护成本大大增加。而写了Initial()方法，那么只要集中修改Initial()就行了。

既然DRY是关于“一个方法，实现一个需求”的，那么，是不是可以把DRY应用到需求分析中？呵呵，答案是肯定的，而且，个人认为，这是个非常好的主意。多个重复的需求可能导致多个重复或者相近的类，最后导致重复代码。所以DRY绝不仅仅对代码适用，它是一个广泛适用的原则。

3. SUBTRACTION减法原则

减法原则是我们自己提出的，意思就是给程序员做减法。一般来说越到底层的程序员，工作时间越短、技能越弱、经验越少。但是实际工作当中，你会发现越到底层的程序员要做的事情越多，要用的技能也越多。Tiny构建者认为，这也是现在程序员工作效率低、质量差的重要原因。因此我们认为应该给程序员做减法，越到底层的程序员做的事情要越单一、越简单。

4. 下级服从上级原则

可能有人在笑了，这个也算原则？确实，它就是原则，只不过原来下级服务上级是挂在嘴上的，而Tiny框架则从框架层级做了限制，使得下级必须服务上级。这两点主要体现在流程及页面实现中，上级经理可以对下级完成的工作内容进行强制性要求实现，不同的是流程是采用显式继承的方式，而页面是隐式继承的方式

5. 单一原则

几乎每个熟悉Tiny框架的人可能会问同一个问题，那就是：为什么Tiny分了这么多的工程？Tiny框架的构建者也深深的知道这样会增加相当的集成工作，但是这样做的好处是可以把单一原则进行强制性的约束，使得一个模块只解决单一模块应该解决的问题，从而避免不同的问题放在一起解决所导致的胡子眉毛缕不清的问题，同时也避免了不恰当的依赖及模板引用。

6. 模块化与自动组装原则

一般的软件开发，整个集成过程都需要人员小心翼翼，要配这个配那个，稍不小心就会有这种那样问题的出现Tiny框架构建者也常常知道这一点给集成人员带来的困难及给软件开发测试带来的巨大的工作量，因此在整个Tiny框架的构建过程中，都非常注重集成过程的自动组装，要求做到扔进去不用管，由框架自动集成。Tiny框架构建者深深知道，模块化对于软件开发过程中开发、高度、集成、发布、维护过程中所起的作用及节省或花费的巨大成本。因此提出了业务单元(Business Unit)的概念，使得与模块相关的所有内容都可以放在一起。

7. 集中配置原则

在Tiny构建者多年的工作过程中，被配置的问题所常常困扰，在开发期有许多问题是由于配置不当引起，在测试在发布及升级过程中，也有相当多的问题是由于配置不当引起的。在Tiny框架我们对配置做了大量的工作，一个是COC方式，如果不配，则采用系统默认的值；一个是集中原则：把需要人工需要配置的内容都集中起来统一配置；一个是对于不需要人工干预的配置，那就集成在Jar包中，作为发布者发布项的一部分。