TOC

一些不足道哉的开发经验

作者：
日期：
标签： 开发者

  1. 编码：
  2. 遵守一个社区比较公认的编码规范和编程实践，不要试图自己搞一套。
    尤其是命名风格保持统一。
  3. 拆分的思想：分服务，分模块，分文件，分函数，分层。
    不同部分之间的依赖应该非常清晰，严禁无序调用。
  4. 代码复用：尽可能不要重复写类似的代码。
    业务无关代码应该采用公共库，组织内复用，不要重复实现相同的逻辑
  5. 对于功能实现应该有一定的预留空间，对可能发生的调整有一定的包容性
  6. 函数简单：一个函数应该尽可能简单，代码行数少，逻辑清晰。
  7. Git：
  8. 分支管理
  9. 提交管理
    1. 每次代码提交应该有一个明确的目的，和这个目的无关的代码应该另外提交。
      尽可能保证每次提交修改的量比较少。
    2. 提交的时候应该做代码风格检查，没有通过的拒绝接受
  10. 测试：
  11. 单元测试必须要有, 要比业务代码接受更严格的检查
  12. 我认为写单元测试的时间应该开发的时间差不多
  13. 覆盖率要求
  14. 为了保证测试的便利，可以对现有实现进行调整（开发时就应该考虑到测试流程）
  15. 集成测试，回归测试，功能测试，性能测试
  16. 自动化：
  17. 自动化测试
  18. 自动化部署
  19. 日志：
  20. 格式统一
    重点是要能方便地定位到问题, 比如对于同一个请求的所有日志加上相同的标识
  21. 日志级别一定要分清楚，方便做异常监控
  22. 日志监控
  23. 对于请求响应类型的服务，建议分成以下日志文件：
    1. main.log / app.log 主日志，INFO 级别, 保留 15 天
    2. trace.log 调试日志，DEBUG 级别, 保留 3 天
    3. error.log 异常日志，ERROR 级别, 保留 30 天, 可以考虑加上
    4. monitor.log 监控日志
    5. access.log 访问日志
    6. api.log API 调用日志
    7. event.log 重要的时间点记录下来，比如 REQUEST_START, REQUEST_END 等, 保留 30 天
    8. data.log / db.log 数据库操作（包含 Redis）, 保留 30 天
    9. message.log / mq.log MQ 消息, 保留 30 天
  24. 对于有监控需求的日志应该加上特殊标识，比如 Monitor:Daily, Monitor:5m, Monitor:UpstreamError
    这个根据监控策略来。
  25. 新开发的逻辑可以加入尽可能多的调试信息，日后根据实际情况调整。
  26. 设计：
  27. 需求评审之后，就要做设计评审（方案评审）
    1. 如果涉及数据库调整，应该由数据库团队参与评审
    2. 如果设计加购调整，应该由架构团队参与评审
  28. 对外接口调整需要谨慎
  29. 其他：
  30. 应当尽可能了解自己参与的项目，重要的数据应该能记住，比如重点客户信息，性能指标，流量等。
发布于码厩技术博客的所有文章，除注明转载外，均为作者原创，欢迎转载，但必须注明出处。
尊重他人劳动，共创开源社区！转载请注明以下信息：
转载来源： 码厩技术博客 []
原文标题：一些不足道哉的开发经验
原文地址：
知识共享许可协议