- 清晰的需求
- 需求要有文档；方便后续追溯或交接等
- 需求是基础，必须详细；多和需求沟通确认，不可模糊、模棱两可，否则后续可能越错越远
- 抽象建模
- 分析需求；梳理清楚关联关系，建立数据模型和关联
- 画E-R图；思考、抽象表关系和表字段
- 评审；可以的话，请教业务透彻同事，评审数据表
- 数据库建表
- 尽量遵循数据库三范式
- 字段命名规范，避免使用数据库关键字
- 避免过度设计，比如一些多余的字段，增加了歧义和维护成本
- 合适的字段类型和字段长度
- 合适的冗余来减少表关联
- 评估哪些字段需要建立索引；
- 一些非重字段，可建立唯一索引，
- 一些频繁用来查询或关联字段，可建立索引
- 索引不是越多越好，有维护成本
- 区分度不高的字段，不建议索引
- 尽量将字段设置为not null；
- 可以防止出现空指针问题
- null值可能会使运算变复杂
- 可通过设置默认值方式，保持not null
- 编写接口
- 明确需求，定义主体流程步骤
- 先满足接口功能需要
- 代码重构优化
- 修改已有接口，注意保持和原有兼容
- 可读性；合理注释、隔行
- 复用性；提取公共代码
- 提取函数；单一功能摘取为小函数，避免过长函数
- 扩展性；是否适用设计原则、设计模式等
- 入参检验；可避免大部分入参导致的错误
- 接口防重、限流、防刷；一些重要接口，尤其对外接口，需考虑幂等性、接口防刷等
- 异常和事务处理；对接口可能抛出的异常，以及事务是否回滚及生效，须考虑清楚
- 可追溯；记录日志，关键操作信息做持久化处理，方便后期追溯、排查
- 并发线程安全；在高并发场景下，类似“查询+修改”的场景，有可能出现数据不一致的清空；此时，通常需要加锁，并注意锁的粒度
- 调用第三方接口时，考虑异常、超时等情况处理策略
- 合理使用缓存；对于读多写少，且数据时效性要求低的场景，使用缓存可以提升查询效率，减轻数据库压力
- 合理使用批量操作；能批量操作时，就不要使用for循环调用；但对于海量数据，须拆分为小批量操作，分而治之
- 谨慎使用异步；遇到一些不影响核心流程准确性，但是较耗时的操作，可以考虑使用异步；
- 谨慎使用并行；在执行多个相互独立（没有先后顺序）的操作时，可以考虑使用并行，充分使用多核CPU优势
- SQL优化；对持久层的SQL进行优化，提升接口性能
- 测试接口
- 单元测试：测试每个方法的正确性
- 功能测试；业务核心流程是否通畅、正常提示、无系统异常
- 数据准确性测试：数据是否符合预期、数据边界、精度、计算结果是否准确
- 事务测试；抛出异常，是否需要或正常回滚，回滚粒度是全部回滚，还是部分回滚
- 并发测试；代码是否存在并发安全问题，在高并发下，是否幂等、防刷、降级、可用等
- 性能测试；在高并发或者海量数据时，接口能否正常响应，是否满足实时性要求
- 追溯测试；接口正常执行、异常报错后，是否有日志或监控可追溯或复现操作历史记录
- 输出接口文档
