这个话题有点大，过去的带团队经历有点心得写下来。有几点我认为是非常重要的
- 遵守流程
- 崇尚规范
- 骨干和执行力
- 技术氛围
- 业务思考
一、遵守流程
无规矩不成方圆，尤其后端系统，有太多环节会影响服务质量。
- 开发流程
- 和产品评审功能和排期，给出上线deadline
- 和测试评审技术方案和测试用例
- 涉及到DB、缓存结构、API或者消息协议等的变更需要有严格的技术评审
- 周期较长的需求开发，需要及时定期同步进度信息
- 完善的UT和自测，确保没问题再提测
- 代码review要严格，除了满足功能，代码规范、性能、优雅等都要考虑
- 有压测必要的，要过一下压测
- 上线流程 需要严格遵守如：测试->(压测)->预发验证->灰度节点->看日志和监控->继续灰度和上线->看日志和监控
- 线上操作 如迁移、升级等，要有详细的操作流程，要有技术评审。比如是否有兼容性问题、是否影响服务、是否影响业务方和用户，重要时候需要邮件通知和公告。
- CASE STUDY 哈哈，这个是一定需要的，避免同样的错误多次犯，更避免流程上的错误多次犯
- 演习和压测 最近也在搞演习平台，演习常常能防范于未然，压测也能发现性能瓶颈
二、崇尚规范。
有人说，谁掌握了标准，谁就掌握了这个行业的未来！放到团队内部的技术规范，更是如此。如：
编码规范。这点毋庸置疑，团队内部肯定遵从统一的编码规范，每个语言都有自己的编码规范。这里不作细述
-
代码review规范
- 具体review规范 各种代码规范、性能点、设计规范等等
- 先review再提测
- 大的mr建议拆成小mr
-
项目文档规范。文档要和代码尽量保持同步。一个标准的项目技术文档，通常包括：
- 接入指南 接入的流程等，对于平台项目尤其注意业务接入的流程
- API文档 API要标准，要和代码保持一致
- 项目介绍 偏介绍业务架构，业务之间依赖关系，业务的背景、功能等
- 项目架构 大的架构设计图以及主要功能的流程图
- 存储和缓存设计 DB的设计，主要缓存结构设计
- 运营后台 如果有
线上维护规范 主要指完善的监控和告警，其他文章里有提到
三、骨干和执行力
能力越强，要求越高。团队要有骨干，骨干要担责。重要不紧急的事情要注重推进节奏和质量。基本上我喜欢用milestone+issue的方式迭代推进，技术路线和方案要评审。紧急但不重要的事情要建立责任意识，注重线上质量。
四、技术氛围
技术氛围是也很重要的，整个团队要对技术保持敬畏和期望。比如半年后、一年后我们的技术突破在哪里？比如平时鼓励技术分享、尝鲜新技术、新员工或者新项目的项目串讲等等~
五、业务思考
技术最终还是为业务服务的，要不断的梳理业务架构、理解产品和业务。技术不仅要满足业务高速发展迭代，有时候也需要更多的考虑如何从技术角度给业务带来发展等。有时候是新的玩法，有时候是提升效率，等等。
