个人体会：技术团队怎么带

这个话题有点大，过去一年多的带团队经历，主要是个人体会和总结，完全不敢谈经验，希望能抛砖引玉~

一、崇尚规范。

有人说，谁掌握了标准，谁就掌握了这个行业的未来！放到团队内部的技术规范，更是如此。如：

• 编码规范。这点毋庸置疑，团队内部肯定遵从统一的编码规范，每个语言都有自己的编码规范。这里不作细述
• 代码review规范
  • 提测前review，而不是测完再review
  • 大的mr建议拆成小mr。如果确实属于大mr，比如新项目或者重构，那么可以组织多人会议室review
  • 保证一个mr至少两个人+1。同时，如果出现明显bug而导致线上问题，那么+1者要"连坐"
• 项目文档规范。文档要和代码尽量保持同步。一个标准的项目技术文档，通常包括：
  • 接入指南 接入的流程等，对于平台项目尤其注意业务接入的流程
  • API文档 API要标准，要和代码保持一致
  • 项目介绍 偏介绍业务架构，业务之间依赖关系，业务的背景、功能等
  • 项目架构 大的架构设计图以及主要功能的流程图
  • 存储和缓存设计 DB的设计，主要缓存结构设计
  • 运营后台 如果有
• 线上维护规范 主要指完善的监控和告警，其他文章里有提到

二、崇尚流程

无规矩不成方圆，尤其后端系统，有太多环节会影响服务质量。

• 开发流程
  • 和产品评审功能和排期，给出上线deadline
  • 和测试评审技术方案和测试用例，给出提测deadline
  • 涉及到db、缓存结构、api等的变更需要有严格的技术评审
  • 周期较长的需求开发，需要及时同步进度信息
  • 完善的UT和自测，确保没问题再提测
  • 有压测必要的，要过一下压测
• 上线流程 需要严格遵守如：测试->(压测)->预发验证->灰度节点->看日志和监控->继续灰度和上线->看日志和监控
• 线上操作如迁移、升级等，要有详细的操作流程，要有技术评审。比如是否有兼容性问题、是否影响服务、是否影响业务方和用户，重要时候需要邮件通知和公告。
• CASE STUDY 哈哈，这个是一定需要的，避免同样的错误多次犯，更避免流程上的错误多次犯
• 演习 最近也在搞演习平台，演习常常能防范于未然，发现各种惊喜

三、技术氛围

技术氛围是也很重要的。比如鼓励技术分享、尝鲜新技术、新员工或者新项目的项目串讲等等~

始终记住，你的高度和深度会影响你带的同学，如果你不达标，你不去深挖，那么怎么一起成长呢