个人体会：技术团队怎么带
2018-12-06 本文已影响11人
imnx
这个话题有点大，过去一年多的带团队经历，主要是个人体会和总结，完全不敢谈经验，希望能抛砖引玉~
一、崇尚规范。
有人说，谁掌握了标准，谁就掌握了这个行业的未来！放到团队内部的技术规范，更是如此。如：
- 编码规范。这点毋庸置疑，团队内部肯定遵从统一的编码规范，每个语言都有自己的编码规范。这里不作细述
- 代码review规范
- 提测前review，而不是测完再review
- 大的mr建议拆成小mr。如果确实属于大mr，比如新项目或者重构，那么可以组织多人会议室review
- 保证一个mr至少两个人+1。同时，如果出现明显bug而导致线上问题，那么+1者要"连坐"
- 项目文档规范。文档要和代码尽量保持同步。一个标准的项目技术文档，通常包括：
- 接入指南 接入的流程等，对于平台项目尤其注意业务接入的流程
- API文档 API要标准，要和代码保持一致
- 项目介绍 偏介绍业务架构，业务之间依赖关系，业务的背景、功能等
- 项目架构 大的架构设计图以及主要功能的流程图
- 存储和缓存设计 DB的设计，主要缓存结构设计
- 运营后台 如果有
- 线上维护规范 主要指完善的监控和告警，其他文章里有提到
二、崇尚流程
无规矩不成方圆，尤其后端系统，有太多环节会影响服务质量。
- 开发流程
- 和产品评审功能和排期，给出上线deadline
- 和测试评审技术方案和测试用例，给出提测deadline
- 涉及到db、缓存结构、api等的变更需要有严格的技术评审
- 周期较长的需求开发，需要及时同步进度信息
- 完善的UT和自测，确保没问题再提测
- 有压测必要的，要过一下压测
- 上线流程 需要严格遵守如：测试->(压测)->预发验证->灰度节点->看日志和监控->继续灰度和上线->看日志和监控
- 线上操作如迁移、升级等，要有详细的操作流程，要有技术评审。比如是否有兼容性问题、是否影响服务、是否影响业务方和用户，重要时候需要邮件通知和公告。
- CASE STUDY 哈哈，这个是一定需要的，避免同样的错误多次犯，更避免流程上的错误多次犯
- 演习 最近也在搞演习平台，演习常常能防范于未然，发现各种惊喜
三、技术氛围
技术氛围是也很重要的。比如鼓励技术分享、尝鲜新技术、新员工或者新项目的项目串讲等等~
