2019-11

  1. 记录大家的建议和愿望清单
  2. 根据公司OKR, 选取1-2项可执行的建议, 梳理具体的执行计划

ZhangMilai Want

Why

紧接着推进强制性的code review与对命名的重视, 推行命名的方法论和工具从而使代码质量推进落地执行。 本月只针对接口的拆分和设计进行追踪。

个人认为接口的设计友好体现在：

  • 让前端|测试人员在了解业务后能迅速地找到对应的接口以及调用方法
  • 能够根据客户或前端市场人员反馈的描述(而非技术性描述)进行接口的debug或修改维护
  • 尽量根据对业务的理解知道哪些接口是重要和需要高频修改的（涉及到测试|安全力度, 架构方法）

期望与验收

  • 低 能够针对业务模型建立进行纸上谈兵, 产生理解业务的意识
    • Dev
      • 能够用中英文描述自己现在进行项目的角色
      • 能够用中英文描述自己现在进行项目的业务命令以及对应的接口地址
    • TL
      • 能够用中英文描述自己现在进行项目的角色
      • 能够用中英文描述自己现在进行项目的业务命令以及对应的接口地址
      • 分享在命名和架构上的考虑(现在存在的问题、未来的演进方向)
  • 高 能够在生产产出上提现业务模型, 运用业务意识提升对外输出质量
    • Dev
      • Jira、Commit、分支的名词使用统一的业务命名
      • 根据TL提供的名词, 命名代码文件
      • 根据TL提供的名词, 命名函数方法
    • TL
      • Jira、Commit、分支的名词使用统一的业务命名
      • 与市场沟通，针对自己的项目整理一套业务名词
      • 在每个业务开发前和Dev、Market进行设计架构的梳理和命名
      • 对Dev的提交进行code review, 根据经验提出命名的修改建议
      • 梳理API文档，如有必要进行低成本的文档重命名（比如文档上的业务名词是Team, 但是实际的请求地址是/positions）

设计思想

工具

  • swagger

results matching ""

    No results matching ""