仙人抚我顶，使我生长发

• 完成业务逻辑时，要先将业务逻辑分块，每块封装成一个有语义化的方法，然后填充方法。不要从头一个方法写到尾，这样的代码可读性较差并且内聚性较高。
• 在了解项目代码的过程中太过于专注在代码方面，只了解逻辑实现而没有与现实的业务逻辑所联系，对主要数据模型的相互流转过程关注度不高。导致对项目逻辑理解效率不高
• MateQ的消息消费任务要考虑相同任务的并发问题以及幂等性
• 嵌套if尽量不要在两层以上，要使用并行if逻辑
• 使用方法时想当然的使用api但却没有仔细了解过，也没有去搜寻是否有满足自己需要的api。行动上的勤奋不能忽略思想上的懒惰，第三方或者其他人的api一定要验证后在使用，要对自己负责
• 先考虑各个交互的接口，在设计数据结构
• 改任何代码都要跑一下单元测试 稳中求胜
• 边界条件的考虑，对于异常的处理
• 每次的查询，修改和新增都要考虑必要条件和造成的影响
• 对于一个接口要考虑的方面
  • 功能性需求；明确接口功能的具体定义，职责单一化。确定接口需要接收的参数，参数的类型、默认值以及哪些是必需的。定义统一接口的返回值 code、info、data，包括成功和失败情况。
  • 非功能性需求（监控一些性能指标、熔断、降级、限流）；分析接口的响应时间、计算性能、吞吐量等，确保能满足业务场景下的需求。接口的异常处理机制、重试策略、失败恢复等。
  • 安全性；身份、权限、加密、防攻击
  • 设计与结构；RESTful风格/GraphQL：选择适合业务场景的设计风格。版本号和幂等性。
  • 可扩展性；考虑未来可能的功能扩展，预留扩展点。设计时考虑哪些参数可以通过配置来实现变化。另外还有接口模块的可插拔性和独立性。一般还有组件的设计引入。
  • 可维护性；确保接口代码的可读性和注释的完整性。日志和监控：接口请求日志、异常日志以及监控指标（如调用次数、失败率等）。设计良好的junit单元测试和对应的数据以及集成测试，确保接口质量。
  • 耦合度与复用性；接口与其他模块的依赖关系是否合理，避免过度耦合。接口设计是否通用，能否在不同模块或项目中复用。
  • 文档与上线；使用Swagger或者其他文档工具生成清晰的接口文档。另外是灰度发布策略、回滚机制，确保接口上线后的稳定性。一般是统一动态组件控制。