TOC

一些不足道哉的开发经验

  1. 编码:
    1. 遵守一个社区比较公认的编码规范和编程实践,不要试图自己搞一套。
      尤其是命名风格保持统一。
    2. 拆分的思想:分服务,分模块,分文件,分函数,分层。
      不同部分之间的依赖应该非常清晰,严禁无序调用。
    3. 代码复用:尽可能不要重复写类似的代码。
      业务无关代码应该采用公共库,组织内复用,不要重复实现相同的逻辑
    4. 对于功能实现应该有一定的预留空间,对可能发生的调整有一定的包容性
    5. 函数简单:一个函数应该尽可能简单,代码行数少,逻辑清晰。
  2. Git:
    1. 分支管理
    2. 提交管理
      1. 每次代码提交应该有一个明确的目的,和这个目的无关的代码应该另外提交。
        尽可能保证每次提交修改的量比较少。
      2. 提交的时候应该做代码风格检查,没有通过的拒绝接受
  3. 测试:
    1. 单元测试必须要有, 要比业务代码接受更严格的检查
    2. 我认为写单元测试的时间应该开发的时间差不多
    3. 覆盖率要求
    4. 为了保证测试的便利,可以对现有实现进行调整(开发时就应该考虑到测试流程)
    5. 集成测试,回归测试,功能测试,性能测试
  4. 自动化:
    1. 自动化测试
    2. 自动化部署
  5. 日志:
    1. 格式统一
      重点是要能方便地定位到问题, 比如对于同一个请求的所有日志加上相同的标识
    2. 日志级别一定要分清楚,方便做异常监控
    3. 日志监控
    4. 对于请求响应类型的服务,建议分成以下日志文件:
      1. main.log 主日志,INFO 级别, 保留 15 天
      2. trace.log 调试日志,DEBUG 级别, 保留 3 天
      3. error.log 异常日志,ERROR 级别, 保留 30 天, 可以考虑加上
      4. event.log 重要的时间点记录下来,比如 REQUEST_START, REQUEST_END 等, 保留 30 天
      5. data.log 数据库操作(包含 Redis), 保留 30 天
      6. message.log MQ 消息, 保留 30 天
    5. 对于有监控需求的日志应该加上特殊标识,比如 Monitor:Daily, Monitor:5m, Monitor:UpstreamError
      这个根据监控策略来。
    6. 新开发的逻辑可以加入尽可能多的调试信息,日后根据实际情况调整。
  6. 设计:
    1. 需求评审之后,就要做设计评审(方案评审)
      1. 如果涉及数据库调整,应该由数据库团队参与评审
      2. 如果设计加购调整,应该由架构团队参与评审
    2. 对外接口调整需要谨慎
  7. 其他:
    1. 应当尽可能了解自己参与的项目,重要的数据应该能记住,比如重点客户信息,性能指标,流量等。