项目回顾
重构目的
优化授权数据的存储方式，避免原先冗长的缓存计算
成果
无需再做定时的缓存刷新，据实施和客户反馈操作授权速度和流程度比原先有大幅提升
槽点和败笔
- 从目的出发业务基本无改动，完全搬运原先代码,也因此出现了一些纰漏
- 过度设计，ra-backend无意义的透传，首先侧重代码的清晰、可读性，再考虑其他规范，避免形式主义
- 缺少自测手段,过度依赖测试团队,效率很低
- 前期在基础组件花费时间过长，缺乏进度管控,后期赶工,代码质量缺少保障
- // 沟通问题
开发体感
业务代码
- 修改依赖授权数据的项目非常痛苦,要去了解原先的业务场景和数据格式后再设计接口，在后期测试时，这块花费了很大时间，出了bug难以排查
- 原先项目参数定义比较奇怪，使用-1表示否定，mongo支持undefined为查询条件
基础组件
- 缺少服务地址组件： 本地开发启动多服务联调比较麻烦，连接线上服务也需要不断修改配置文件
- log插件：线上报错信息不完整，没有显示具体的调用信息
工程化
解耦
- 服务拆分颗粒度 要与公司业务发展趋势相契合，不能生搬硬套教程，做适当整合(基础信息类)
- 避免类似ra-backend只做透传的项目
- 传入参数的校验，存在将前端传入参数直接透传查询的情况，需要加以验证和鉴权
模块化
- 因为docker构建缓存，私有包不自动更新,增加Jenkins配置或者写明使用包版本
- 私有包版本管理，不兼容问题
质量保证
- 最小单元测试 确保不出现语法错误(await、拼写)
- 健康检查，考虑开放http来提供健康检查，通过fx-rpc插件实现再调用rpc来自检
代码风格
- 下划线转驼峰
- 单文件代码行数,按controller映射service容易出现代码行数过大 需要做适当拆解
临时发布环境搭建
测试
测试准备
- 撤下老的项目，防止再被调用
自测能力
对复杂业务场景的自测能力
沟通
团队会议
- 回顾本周进度，指定下周计划，预防延期或及时做进度调整
- 对于有争议的问题由tl做决策避免拖延
- 确定责任边界，避免扯皮;回顾、调整目标，确保团队整体方向正确（避免无用功，有争议时从目标出发）
- 做好会议记录（记录决策）发给与会者
下阶段计划
rpc包更换
- 精简rpc包，剔除mq功能
- 使用egg agent,支持多worker启动
mq包更换
- 封装http版本的包
- 避免一个业务动作批量发送mq的场景（类似多段的分布式事务） 需要由业务侧做拆分
log
- 错误日志输出适配rpc，打印调用参数和traceId
减少rpc传输字段
- 禁用select * ,自协调参数输出
服务地址组件
- 暂定在本地开发使用，线上运行不依赖它
- 通过简单的声明即可获取服务地址，包括测试、预发、生产
技巧分享
在node中实现高效缓存
http://wmtcore.com/2020/04/23/%E9%AB%98%E6%95%88%E7%BC%93%E5%AD%98%E7%9A%84%E4%BD%BF%E7%94%A8/