规范约定

使用统一的规范，便于统一大家的思想认知，降低出错的概率；不要等出现问题了才想到解决，而是准备好了，才不会出现问题。

有规范一定会产生制约，虽然规范制定时希望能够最大程度的兼容大家的开发习惯，以降低大家的不适应程度，但是众口难调，难免有一些地方会跟一部分人的习惯产生冲突。但是没有绝对的对错，适当的规范和标准绝不是消灭代码内容的创造性，而是限制过度个性化，以一种普遍认可的统一方式降低协同成本，提升协作沟通效率。

如何落实

前期除了一些固化在框架里的规范之外，其它的规范主要还是靠大家自觉执行，以及通过适当的代码走查来保证。后期可以考虑提供一些工具来保障规范的执行，比如集成在代码质量管理流程中自动执行检查等。

box-api（固化在框架里的一种代码层面的规范）

box-api项目里边基本都是接口，和少量的一些方便开发过程中使用的快捷操作类。

box-impl项目是当前基于spring框架封装的默认实现版本。

box-springboot项目是增加了springboot环境依赖的版本。

如果你有兴趣也可以提供自己的实现版本，前提是必须提供box-api的绝对兼容性，即基于box-api开发的项目应该在不做任何修改的情况下能稳定运行于你的发行版。

所以接下来当我们需要特定功能时，应该尝试着去基于api来思考问题，而不是基于具体的实现，接口中定义的行为基本上就决定了功能的使用方式与使用规范。

比如在需要缓存功能时我们考虑的应该是我们实际想要达到的效果是什么，基于我们的需求来抽象接口行为，而不是具体的redis或者ehcache组件提供了什么样的API使用方式来决定我们在使用上的规范。

box-api中的任何组件都可以被替换，如果api中的某个组件无论是性能还是结果等任意一个方面达不到期望的目标值，都可以很轻松的自行替换，而不用必须等待框架的版本发布。

举个例子吧，如果项目开发过程中发现了StringUtils工具的行为在特定环境下与预期结果不一致，而且时间又很紧迫，走框架更新流程来不及，此时可以在框架配置文件中配置StringUtils工具切换到项目组自己的实现，自行掌控问题处理进度。有空闲时间后再提交相关问题到框架组，待框架更新发布后，在下次升级时移除自定义配置项即可，以此达到框架组与产品组之间的一种高效协作方案。

一些约定

框架注解类

为了方便大家记忆，框架中提供的注解基本上都有box前缀，如BoxDao，BoxAction，...

项目包

建议每个项目规范好自己的项目包名，将项目启动类放置于项目包名下，遵守此约定，可免于配置dao包目录，action包目录等信息。例如项目包名为“com.test.project1”，则约定部分如下：

• com.test.project1.App.java - 项目启动类
• com.test.project1.action - action包
• com.test.project1.entity - entity包
• com.test.project1.dao - dao包

分模块

分模块的项目，模块应该归在项目包下，例如项目包名为“com.test.project1”，模块1为module1，模块2为module2，则约定部分如下：

• com.test.project1.module1 - 模块1包名
• com.test.project1.module2 - 模块2包名

模块工程划分为：api（模块接口），impl（模块实现），route（项目路由），web（web环境启动项目），如下：

• module1-api
• module1-impl
• module2-api
• module2-impl
• project1-route
• project1-web