经验积累

经验积累

• 如果某个接口有用到缓存，最好在接口请求的时候加一个是否走缓存的字段，这个字段可以不用对外暴露，它的作用是如果线上改了数据库等需要更新缓存，或者改了逻辑需要验证的时候就可以加上这个字段请求一下。不用等到缓存到期，有些缓存的时间比较长非常不好验证。

• 后端开发一个对外提供的http接口的时候，我们应该站在一个调用者的角度去思考接口的返回是否方便调用者调用，举个例子，查询user 的列表数据，返回的字段有id和userId这两个字段，查询user详情的接口的入参到底用这两个id哪个id呢？如果是用id来区分唯一的一条记录的，那么这个userid这个字段时候还需要是不是名字有问题，或者改为userCode.如果不用数据库唯一主键id来做区分，用自己的userId,那么数据库唯一主键id在接口中就不要返回，以免引起调用者的误解。tip 虽然是个小小的问题，但是如果设计好了（最好是用数据库唯一id来区分）无论从接口的开发，文档的定义，数据库的设计，多开发人员协作开发上都有很大的好处。

• 关于微服务拆分之后的为满足需求的各种查询的思考，举个例子：有一个用户服务 user-service,有一个技能服务 skill-service。需求：查询某个用户下的技能（通过技能的一些属性进行过滤）。skill-service对应的数据库里面有 skill（技能表） user_skill（用户技能关系表），那么查询的时候没什么问题直接连接查询就可以了。但是也有这种情况，skill表和user_skill不在一个表里面，比如skill存在mongodb user_skill却存在mysql里，那这种情况的查询在设计的时候就应该考虑把skill条件查询的字段通过接口调用 mq等方式冗余到user_skill这个库里面。

• 创建一个maven的java项目的时候用什么结构呢，是父子项目（dao、service、controller是单独的子项目）？还是就一个单个的pom项目（dao、service、controller在一个项目中）。虽然都可以，但是父子项目相比开发比较麻烦，有什么不同人员开发开发有不同的理解，也有可能分子项目分的太细，把entity，Model这些都分开，这样及其不好。根据我们的项目的部署以及功能需要可以这样创建项目。

  1、如果项目是提供微服务的这种方式，独立部署的，创建一个项目 分为service和api这两个子项目，api就是声明接口的，service是逻辑，entity vo等放在api层 service应用api层

  2、如果项目是web和app服务单独部署的有给web提供的controller 也有给app提供的gateway 那么项目应该分开发service 、controller、dao也可以分开。entity vo 单独分一个common 只能其他层引用common

• 如果一个需求要评审，那么就应该通知相关开发人员，因为在需求评审的时候，其实就是在开发人员脑海中构思的时候，什么地方有问题，合不合理他就是最有发言权的。评审过后没问题着手开发的时候，我们应该先考虑怎么测试，或者说怎么自测。如果是个简单的接口那很简单，但是如果不是，假如说是类似上报数据，我们拿到数据做计算，做统计，这种的我们就应该先根据上报的协议写一个模拟上报的程序。虽然复杂但是为以后的开发打好了基础。也可以给团队人员共享。