PRD或相关域评审时：
- 评论不清楚的点
系分：
- leader参与
- 任何变更需要及时同步系分和相关同学；
- 不确定的点需要截图保留在系分中；
开发及自测：
- 没完备的评估系分前，千万不要动手写；系分要求细致！！！要反复的修，思考主要在这个阶段；
- 根据系分，想清楚实现代码，同时单测完全覆盖，一定要验证每一个方法，数据库操作，不只是为了覆盖率；
CR：
- leader参与
- 使用到平台方的接口，需要在行业CR前找平台同学进行CR，确定版本、使用方式、风险点
联调：
- 联调环境的分组无效时，请求被其他地方的机器受理的情况，注意怀疑是不是应用假运行中，简单的可以使用tr ui调用相关接口，以验证应用是否在启动中；
发布计划和风险评估：
- leader参与
- 在评审阶段主动发现并暴露风险；
发布及配置变更：
- 一定要十分小心，找主系分一再确认；
- 观察业务服务监控
- 尤其注意当前配置影响原有链路的情况，对于更改现有配置，无论是新增还是删减都要按照完整的流程进行验证和double check
拉会处理问题：
-
说明背景（业务、问题）
-
把问题留在团队内部，判定是否需要及时知晓leader
-
新接入依赖方，不应该只是去借鉴已有系统怎么弄的，使用的什么接口，而是直接让平台的人推荐并确认用什么（询问接口文档），避免因为新老交替时候的兼容性问题
案例：老租户人群列表查询
在编码前，先用TR把关键步骤的逻辑和参数弄清楚，并且找平台的人确认方案的可行性以及可能存在的坑点
案例：创建规则的时候自以为按照什么方案可行，其实没有得到准确的说法前，都不要推测他人的做法和说法
PRD需求要拆解为几个纬度来评估：
-- 新增功能
-- 改造功能
-- 表面功能
-- 隐藏功能
系分阶段的调研时间要足够的把方案讨论清楚，不要等到中途CR的时候再改造，这样会变得十分紧急
案例：小游戏管理时在提测当前CR，结果接下来一星期都在各种改造中
开发环境维护两套：自己用一套，测试用一套
各种地址、Trace、sql、脚本和操作的逻辑要维护在文档中
开发阶段的对接要及时，不要等联调的时候再细对
开发时，接入下游应用的同时，准备好Mock
逻辑式编码，采用自顶向下，先写逻辑接口；然后自底向上，完善内容。
问问题的模版：
○ 打招呼
○ 交代背景和业务需求
○ 遇到的问题描述、trace
○ 相关补充（截图、数据、环境）
○ 希望等到支持、表达紧急、积极拉电话会议
及时记录Trace并简要描述是什么trace；不要开太多的浏览页面，弄完一样弄其他的；要有优先级；最多并发度为2
-
一锁二判三更新是同一个对象
-
事务模版的这些操作一般在service层组装repository
-
分清楚NotBlank\NotNull\NotEmpty的场景
-
错误码的定义要明确
-
定义接口的同时就把注释写上
-
工具类的使用
-
TODO：
○ 补充MyBatis
○ 事务模版
○ 分布式锁
○ 缓存框架使用
○ 服务的抽象