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

这个话题有点大，过去的带团队经历有点心得写下来。有几点我认为是非常重要的

• 遵守流程
• 崇尚规范
• 骨干和执行力
• 技术氛围
• 业务思考

一、遵守流程

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

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

二、崇尚规范。

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

• 编码规范。这点毋庸置疑，团队内部肯定遵从统一的编码规范，每个语言都有自己的编码规范。这里不作细述

• 代码review规范

  • 具体review规范 各种代码规范、性能点、设计规范等等
  • 先review再提测
  • 大的mr建议拆成小mr

• 项目文档规范。文档要和代码尽量保持同步。一个标准的项目技术文档，通常包括：

  • 接入指南 接入的流程等，对于平台项目尤其注意业务接入的流程
  • API文档 API要标准，要和代码保持一致
  • 项目介绍 偏介绍业务架构，业务之间依赖关系，业务的背景、功能等
  • 项目架构 大的架构设计图以及主要功能的流程图
  • 存储和缓存设计 DB的设计，主要缓存结构设计
  • 运营后台 如果有

• 线上维护规范 主要指完善的监控和告警，其他文章里有提到

三、骨干和执行力

能力越强，要求越高。团队要有骨干，骨干要担责。重要不紧急的事情要注重推进节奏和质量。基本上我喜欢用milestone+issue的方式迭代推进，技术路线和方案要评审。紧急但不重要的事情要建立责任意识，注重线上质量。

四、技术氛围

技术氛围是也很重要的，整个团队要对技术保持敬畏和期望。比如半年后、一年后我们的技术突破在哪里？比如平时鼓励技术分享、尝鲜新技术、新员工或者新项目的项目串讲等等~

五、业务思考

技术最终还是为业务服务的，要不断的梳理业务架构、理解产品和业务。技术不仅要满足业务高速发展迭代，有时候也需要更多的考虑如何从技术角度给业务带来发展等。有时候是新的玩法，有时候是提升效率，等等。

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