【工作经验】开发工程师在工作中应该注意的点

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
  ○ 事务模版
  ○ 分布式锁
  ○ 缓存框架使用
  ○ 服务的抽象