明确的需求
需求要有文档：留存文档，一方面方便成员之间学习交流，避免口口相传；另一方面，也是留作证据，方便后期因需求导致的扯皮、甩锅等等。所以，需求文档很重要。
需求必须详细：多和需求沟通确认，不要模糊、模棱两可；很多时候产品对于需求都是模糊的，就让开发来做，后面将会无休止的变更，并让开发背锅，所以需求详细之后再开始，磨刀不误砍柴工！
金额数量要仔细：通常情况下，数量相关的往往和金钱、库存等相关，因此数据准确性就很重要，如果数量出错，往往会导致很严重问题；所以，对于数量相关的取值，是否允许负数、精度怎么取、计算逻辑是怎样、是否并发场景等，需要明确好，采取对应的措施，以防出错。
变更需求（数据）要慎重：实际工作中，可能出现需求考虑不全或人员操作失误等情况，可能需要变更需求（或数据）；这时，产品轻描淡写的一句修改就完了，殊不知变更可能带来大量的工作量或风险；所以切勿轻易接收产品随口的变更，认真评估工作量和风险，风险大时记得向上反馈。
抽象建模
分析抽象：在产品看来，可能注重的是功能，但是对开发来说，关注的是关联和逻辑；因此，硬直翻译功能需求，往往时候不好的，后期很容易变更；更好的是思考、抽象出逻辑和关联关系。
画UML/E-R图：辅助思考、抽象出表关联关系和所需表字段
评审：可以的话，请教业务透彻同事，评审数据表；可以更早发现设计中的不足，避免前人踩过的坑。
数据库建表
- 尽量遵循数据库三范式
- 统一命名规范和字符集：见名知义，避免使用数据库关键字，统一规范，减少歧义，增加可读性
- 避免过度设计：比如一些多余的字段，增加了歧义和维护成本，保持表字段少而精
- 合适的字段类型和长度：不要使用过大的长度，会浪费空间；数值类型，要注意精度问题
- 尽量数字型代替字符型：数字类型更高效、效率更快、占用更小
- 尽量少用Text/Blob类型：Text类型处理时性能远低于VARCHAR；图片等文件不要直接存储在数据表中
- 合适的冗余减少表关联：对于一些不经常改变的信息，可以字段冗余以减少表关联，提升效率
- 评估哪些字段需要建立索引：a. 一些非重字段，可建立唯一索引；b. 一些频繁用来查询或关联字段，可建立索引；c. 索引不是越多越好，有维护成本；d. 区分度不高的字段，不建议索引
- 尽量将字段设置为not null：a. 可以防止出现空指针问题；b. null值可能会使运算变复杂；c. 可通过设置默认值方式，保持not null；
编写优化接口
- 明确需求、顶层设计：明白需求，包含基础的功能需求，以及当前场景要考虑的非功能问题：比如数据量、并发、安全、后期变更扩展等。顶层设计，需要从大局去思考如何设计接口，需要考虑设计原则、设计模式等等。
- 先满足接口业务功能需要：技术服务于业务，最基础的就是接口要能满足功能需要，其次是后续优化
- 修改已有接口，注意保持和原有兼容：当前接口被其他接口调用时，修改接口可能牵一发而动全身。
- 注重可读性：合理注释，代码块之间隔行
- 复用性：提取公共代码，不要重复你自己，也方便后续统一修改
- 提取函数：单一功能摘取为小函数，避免过长函数；使层次更清晰、可读性更好
- 扩展性：面向抽象设计接口，考虑是否适用一些设计模式等
- 入参检验：可避免大部分入参导致的错误；使用卫语句快速失败，避免后续更深的错误
- 接口防重、限流、防刷：一些重要接口，尤其对外接口，根据场景情况，需考虑幂等性、接口防刷等
- 异常和事务处理：正确处理异常，是否需自定义异常、是否需转发异常、是否便于定位；事务是否要回滚、事务失效的场景有哪些，是否要考虑事务的粒度等，这些都要考虑清楚
- 可追溯；记录日志：关键操作信息记录日志，方便后期追溯、定位、排查，必要时做持久化处理
- 并发线程安全：考虑接口是否存在并发安全问题，在并发场景下，类似“查询+修改”的场景，可能出现数据不一致的情况；此时，通常需要加锁，并注意锁的粒度，这会影响程序的性能
- 调用第三方接口时，考虑异常、超时、重试策略等情况
- 合理使用缓存：空间换时间，对于读多写少，且数据时效性要求低的场景，使用缓存可以提升查询效率，减轻数据库压力
- 合理使用批量操作：能批量操作时，就不要使用for循环调用；但对于海量数据，须拆分为小批量操作，分而治之
- 谨慎使用异步：遇到一些不影响核心流程准确性，但是较耗时的操作，可以考虑使用异步，以提升效率
- 谨慎使用并行：在执行多个相互独立（没有先后顺序）的操作时，可以考虑使用并行；充分使用多核CPU优势
- SQL优化：好多的接口性能问题，大部分也是SQL优化的问题，SQL优化也是个大的话题，可自行详细学习
测试接口
- 单元测试：测试每个方法正常执行，无明显异常，可能略显麻烦，但事半功倍
- 功能可用：最基础的要求，业务核心流程是否通畅、正常提示、无明显系统异常
- 数据准确：数据是否符合预期、数据边界、精度、计算结果是否准确
- 事务测试：抛出异常，是否需要或正常回滚，回滚粒度是全部回滚，还是部分回滚
- 并发安全：代码是否存在并发安全问题，在高并发场景下，是否幂等、防刷、降级、正常可用、数据是否正确等
- 性能测试：在高并发或者海量数据时，接口能否正常响应，是否满足实时性要求
- 可追溯：接口正常执行、异常报错后，是否有日志或监控可追溯，可快速定位，已排查复现操作历史记录
持续重构
异常反馈：对于测试或生产上，出现异常的地方，思考异常原因，想办法重构来避免再出现，而不是只零时解决当前问题；
日常重构：日常开发功能时，若发现之前的代码，存在考虑不周、隐藏BUG等，及时修复优化；按墨菲定律讲，可能会发生的，或早或晚会发生；所以及时处理隐藏的BUG，避免直到出现问题才手忙脚乱。