乐书开发者代码规范
乐书网络内部开发分享，非相关人员忽略
说明
此文档作为lebooks开发者的一个编程风格的规范，不仅仅讨论结构是否正确、代码格式是否美观的问题，同时也作为一些约定与标准，以保证代码风格的一致与协调。
与其他任何代码风格指南一样，此文档不可避免地有一些带有个人或团队风格的、不地道的、不被部分人认可的规定与要求，可以共同讨论以及逐步修订。
通用
url中使用连字符
如：http://www.lebooks.me/lishu/api/product-catalogs/1/products，http://www.lebooks.me/product-catalogs
在url（不管是api路径还是前端页面路由）中出现两个单词表达一个完整的意思的情况，都像这里一样采用连字符的方式，而不是下划线或者驼峰。
因为连字符表示将2个词连接，而下划线表示分割，正确的语义利于SEO；不使用驼峰是为了防止某些大小写不敏感的情况。禁止滥用任务注释TODO/FIXME
为保证使用任务注释，如
//TODO，//FIXME的开发者不被干扰，没有使用任务注释习惯的开发者必须及时删除已被处理的TODO任务。
尤其不能滥用eclipse自动补齐代码块产生的TODO注释。
java后端
可能被其他大模块引用的maven module必须添加test case，建议所有具体实现的代码全部添加test case
如果自定义异常作为方法的一种返回情况，必须显示定义在接口层面让调用者感知
java模板类的职责划分
BO (business object)
业务对象，通常作为service层的输入和输出模板，主要与业务层绑定，体现了业务逻辑的向外特性，不会因为视图层的变化而发生变化。
VO (view object)
视图对象，作为rest api返回response的模板，主要与显示层绑定，体现了api用户的需求。
通常VO是对BO的拓展、简化以及组合，在VO比较简单的情况下，可以直接略去使用BO类，但发生视图需求改变而不是业务改变时，严禁直接修改BO以及service逻辑。
RQBO (request body object)
请求体对象，主要作为POST方式的rest api请求体的模板，主要与http request的提交数据形式绑定，体现了api用户的需求。
通常request body中的数据还是交由service业务逻辑去处理，所以在比较简单的情况下，可以直接使用BO对象作为RQBO的模板使用，但是必须保证BO与业务逻辑的绑定关系，RQBO发生变化与BO不一致时，必须另外创建RQBO。
PO (persistence object)
持久化对象。
各种类型object之间的转化，可以借助一下映射工具，如Dozer。
关于基本数据类型与包装数据类型的使用标准
- 所有的POJO类属性必须使用包装数据类型。
- RPC方法的返回值和参数必须使用包装数据类型。
所有的局部变量【推荐】使用基本数据类型。
说明：
POJO类属性没有初值是提醒使用者在需要使用时，必须自己显式地进行赋值，任何NPE问题，或者入库检查，都由使用者来保证。
数据库的查询结果可能是null，因为自动拆箱，用基本数据类型接收有NPE风险。
同样的，在将基本类型的默认值自动装箱的过程中，也可能造成逻辑上的错误，原本的控制变成了0值。
