开发CheckList

  • 开发前
    • 从dev切feature之前检查上次的东西有没有合回来
    • 合代码之后看情况要不要升版本号 是不是升版本看下次切新分支或者合入已有分支
    • 反复确认需求 不要默认
  • 设计/开发中
    • 写方法时考虑是通用方法还是专用的,包括命名、参数等设计要一致
    • 前端组件设计时考虑减少循环调用同一接口
    • 接口给前端使用前要自己顺着页面/业务理顺走通,而不是需要用的时候再改
    • 改方法名要改接口url
    • 查找 Ctrl+Shift+Alt+J
    • is_XX -> xX
    • sql
      • 写dbmirgation前检查版本号
      • 涉及到日期比较 日期计算 考虑性能和使用索引
      • 不能保证正确时用SQL直接改之前要备份数据库
      • 没有绝对必要在update前面不要用SET FOREIGN_KEY_CHECKS=0;
      • 在dbmigration的changelog给id加jira号,方便解决冲突;
      • 数据库脚本稳定以后 开发环境尽量跑liquibase,测试环境一定要跑liquibase
    • BigDecimal 注解@Column(name = "target_percentage", nullable = false, precision = 11, scale = 2),precision属性和scale属性表示精度,当字段类型为double时,precision表示数值的总长度,scale表示小数点所占的位数。
    • 有RequestBody要加consumes = MediaType.APPLICATION_JSON_VALUE
    • 使用
      • Sets.difference(dbTaskIds,tmpTaskIds).forEach();
      • Sets.intersection()
    • 自测场景:
      • 上QA自测的时候,不要先上来就添加数据,要测试完全没有数据时的情况
      • 测试注意同一动作多次操作
      • 自测有小数的场景应该覆盖精确到最后一位的情况
      • 共用组件增加内容要查看其它页面是否多了不该出现的内容以及是编辑模式还是只读模式
    • 提交前检查
      • 重复代码、魔鬼数字
      • 临时变量
      • 命名清晰易懂
      • 声明离用的地方最近
      • 有注释的地方是不是可以抽取新方法
      • 写代码的时候如果要复制粘贴修改,要想一想怎么抽取成通用的方法
  • 提测前
    • code review
    • review完一起改 不要一半一半改
    • 对照原型或描述完整的检查是否实现所有要求,有无遗漏
  • 上ST前
    • 确保自己修改的SQL脚本都提交了
    • 检查前端依赖版本 保证都是release版本
    • 查相关SQL 注释 租户ID等是否正确
    • 给PO过 改文案样式
  • 上ST
    • inhouse:
      • 前端连接 后端连接 上线页面(防止忘记执行SQL)
  • 其他
    • 解决问题前 确认是不是问题 是不是需要解决,能不能不解决 做事也是 为什么 做而不是先怎么做
    • 有bug 先看前后端接口 传数据的地方有没有问题
    • 要闭环 保证事情的结果
    • 答应别人新的事情插队前要问一下
    • 拉别人开会之前准备好相关信息发给大家,不要开会的时候才给别人看
    • 接到别人发过来的东西之后或者给别人发东西之前要检查内容是否合适(文档要检查目录更新)
    • 要上线或者要提测 要保证相关人员或者其他支持在
    • 需求来自PO而不是QA
    • 上线页面
      • 不是一次上线的不要放一起
    • 文档
      • 多版本不要在老的文档上修改,复制一份再改,并且要加上日期和版本号

你可能感兴趣的:(开发CheckList)