业务需求设计表

1. 根据原型图，确定返回接口个数，分析返回的数据结构，返回是list还是对象还是对象嵌套list。分析业务，确定service所需sql，把serive从controller的数据接收必须一个个传给mapper。根据参数中的where条件看看哪些可以合并成一个接口。 确定数据字段、表关系、关联字段、确定sql的数据接收实体，确定sql的mapper方法

2. 分析sql，确定表关系，开始联表查询
   复制一个业务相关基本mapper修改接收的数据实体，新的方法，result加入自己需要查询封装的字段(service单独处理的逻辑字段不要加入)

3. service处理返回的mapper数据，把特定字段set好，返回数据实体，一般就是mapper的返回实体，通常在实体里加个字段。考虑业务上左边必须有数据使用left join还是inner join。根据在navicat里写的sql可以确定需要几个sql，sql操作时不会异常的，每个查询结果都要判断是否为null，来封装返回结果result，牵扯到字段也要考虑字段是否为null，防止下步操作导致空指针异常。以分页为前提思考sql。字符串用工具类判断为空用StringUtils.isEmpty();数字判断为空isNull(),数组判断为空size（）0，前台传参通过转化的对象进行getXnull判断

关于对象的创建。如果多对多，中间表有联合主键对应的属性字段（2，3张表都可以做到），2张表都独立生成mapper文件与对象，联合主键对应的属性字段随便放在一个实体类中即可

附件表图片的确定都是根据sourceid和type确定的

service统一返回result，异常在service抓，打印异常e.printrace

equals参数要在前面

查询sql为null了，包括查询结果字段为null查询数据全为null和前台传参为null了，需要工具类判断处理，否则在返回的对象在调用方法是都可能出现异常。

生成的代码列表条件查询没有id条件

重复性的方法要抽取成service

接口验签失败，使用转发不能加注解

文件上传失败，试试浏览器看看能否访问。

在不写result的映射关系情况下，mapper文件默认按全名匹配和驼峰规则自动赋值。可以保留最全的resultmap查的时候mybatis只会映射这部分字段。

异常no getter，一个是基本类型，需要指定@param名称 ；一个引用类型，那就是查询字段没有指定result的字段映射和select字段列表有无该字段

测试数据不要弄成不合理的

pagehelper分页参数设置为1，1就可以测试分页，而且startpage方法必须放在查询list创建pageinfo对象之前，只会封装查出的list，所以如果新建另一个list的创建pageinfo会失效

三种图片上传方式

数据脱敏：一个是在切面处理或者业务层，一个在数据库

推送使用sourcetree先暂存，再推自己分支，拉master，合并冲突，再暂存，再推自己分支，再拉远程master

如果获取list列表get(i)那么也要判断是否为空，如果get属性为null重新赋值时如果采用null+1 就会报错空指针，接口文档一定要注意，哪些是一定要传，哪些不会传，这样别人有可能就会传null或者空串过来，造成空指针异常，测试数据一定要看他是否必传，传错了是否正常报错；接口接口是否符合预期才行

如果业务上大概率唯一，但实际可能不唯一的数据，如根据token查用户，那么我们要加limit 1

pagehelper会缓存分页参数，可能报错。

测试一定要经过单元测试，单元测试包含了验签等完整操作

前台观察方法调用可以写个alert（）观察是否进入方法，在尝试插件的时候复制样本html然后修改controller的以保证跳转至样本html，最后尝试插件发送url与数据回显，仔细观察样本数据回显后台一定要保证彼此一致才行，这决定后台返回数据格与实体类创建形式。插件使用一般就两个：html结构（按插件要求的来）+ajax请求的url

关于测试：根据接口是否异常来返回：接口执行成功没有数据，返回00，data为空；接口执行失败了，返回code=99以及对应msg，且msg是面向用户和管理员都能看懂的；后台有审核，要提示等待审核，不能只显示成功或失败；对象在调用方法前要考虑这个对象是否为空，是否有数据。公用数据库时，接口与控制台也要联合测试。参数是否必填也要测。

总结：原型图–>sql怎么写，逻辑尽量在sql实现，实在不行再service处理结果集或者用多条sql获取结果集–>几张表，表结构是否规范—>mybatis封装