1. 技术管理者的工作

我们从一次完整项目的发布说起，一次完整项目的发布，大概需要经过这几个大的节点：

项目立项 -> 需求评审 -> 视觉稿评审 -> 技术评审 -> 项目启动 -> 开发 -> 联调 -> 测试 -> 发布。

一线管理者要做的就是保证每个节点的质量，来保证整个项目的质量。通过控制过程质量，来保证结果质量。

1.1. 制定规范

1.1.1. 技术评审规范

在技术评审前要熟悉产品同学提供的产品文档、业务流程图、交互原型图，反复与产品同学确认，在双方达成一致的情况下，再设计技术方案。设计技术方案要从总体到局部，做到面面俱到。

总体：

总体结构图
业务流程图
时序图
核心类图

局部：

功能的变更
数据库字段的变更
业务流程上的变更
上下游接口约定的变更

当技术方案确定了，我们就确定了：

技术选型（前端/后端框架、日志中间件、消息中间件、数据库…）
技术架构（组件与组件之间如何协同工作，如何部署）
技术难点预知（明确存在的技术难点，并确定解决方案）
性能瓶颈预知（明确可能存在性能瓶颈的地方，并确定应对措施）
上下游系统交互（明确在流程中的哪个位置，约定接口文档提供时间、接口联调时间）
功能模块划分（任务拆分和分配）

当技术方案确定了，需要输出文档：

预估开发工期.xlsx，包括系统、模块、功能、功能简述、研发人员、工时(h)、预计完成时间等。

功能除了包括正常的开发工作，还要包括提供接口文档，接口联调，研发自测，文档更新等。

正常的功能开发，拆分成工时的颗粒度最大为 2h，这样的颗粒度能够降低工作的复杂度，使不熟悉相关业务的研发也能够快速上手，比如 2h 就写一个方法。
更新项目文档，包括项目介绍、产品文档、业务流程、系统结构、接口文档、数据字段、外部依赖、其他等。

这个分类可自定义，主要是为了解决当人员发生流动导致系统交接时产生遗漏的问题。

1.1.2. 代码开发规范

接入统一可视化日志平台。
接入统一配置中心平台。
接入统一异常监控平台。
接入统一消息中间件平台。
异常处理规范：直接返回、抛出异常、重试处理、熔断处理、降级处理。
统一 API 规范：HTTP 接口、RPC 接口，Code、Msg、Data 等。
分支开发规范：分支名称规范、热修复规范、上线规范等。
其他规范，大家可以自行补充 …

1.1.3. 代码管理规范

常用的代码管理工具：Git、 SVN。

工具的使用，大家都知道，就不多说了，约定一些基础的规范。

不要提交自己的用户配置，比如 IDE 配置。
不要提交不能通过编译的代码。
要早提交、常提交，提交之前要先更新。
提交信息一定要认真填写，参考如下规范。

<type>(scope)：<subject>，比如：fix(首页模块)：修复弹窗 JS Bug。

type 表示动作类型，可分为：
- fix：修复 xxx Bug
- feat：新增 xxx 功能
- test：调试 xxx 功能
- style：变更 xxx 代码格式或注释
- docs：变更 xxx 文档
- refactor：重构 xxx 功能或方法
scope 表示影响范围，可分为：模块、类库、方法等。
subject 表示简短描述，最好不要超过 60 个字，如果有相关 Bug 的 Jira 号，建议在描述中加上。

1.1.4. CodeReview 规范

CodeReview 检查哪些问题？

规范性检查
- 是否遵循代码开发风格规范、代码开发规范。
- 是否所有的变量都被正确定义和使用，注释是否准确。
健壮性检查
- 是否无意中陷入了死循环。
- 是否存在异常未处理、资源未释放的情况。
- 是否存在运行时错误（数组边界溢出、除以零的情况）。
重用性检查
- 是否存在相同的方法写了两次，是否可以写成通用类、方法、组件等。
安全性检查
- 是否存在 SQL注入、XSS、SSRF、CSRF、越权、文件上传等漏洞。
性能检查
- 是否存在同步执行太慢，需要转成异步执行的情况。
- 是否存在未加缓存，频繁链接 DB 的情况。
- 是否需要使用连接池。

CodeReview 如何执行？

前期准备
- 制定 CodeReview 规范和标准，这样在审查过程中可以有据可依，有理可循。
- 确定 CodeReview 审查者、参与者。
实施期
- 在 CodeReview 前，审查者需将审查内容及审查的规范和标准告知所有参与者和代码作者。
- 在 CodeReview 时，审查者要进行逐项审查，不能因为时间不足等因素一扫而过。
- 在 CodeReview 后，审查者要对发现的问题，给予解决方案，同时进行问题记录，便于事后跟踪。
- 审查者不能只在发现问题时提问，遇到不清楚的代码设计和业务，也可以让代码作者进行讲解，便于自己熟悉整个业务和代码设计。
- 期间营造一个讨论问题、解决问题的氛围，不能搞成批判会，这样会影响大家的积极性。
事后跟踪
- 对发现的问题，确定修复的难易程度以及影响的范围。
- 对发现的问题，确定修复完成的时间点。
- 对发现的问题，修复后要进行验证。

对于技术管理者，需要带领团队对当前的各个项目进行有效的拆分，并明确对应的里程碑，给出合理的排期。

1. 对项目进行分析：

若有延期，需要有充分的理由
若有失误，需要有详尽的复盘
若有临时性需求，需要扛得住压力

2.其次，关注工程效率的指标

按时交付的比例，分析每个月发布的项目中的交付率。
处理线上bug的时效，是否能及时修复
响应紧急需求的时间，能否快速实施

3. 最后，团队自动化的应用比例，是否建立起有效的自动化测试+发布+报警体系

1. 建立业务指标

服务的稳定性、延时等等指标需要有统一的标准。例如：支付成功率、下单成功率等等

例如，对于每天对外暴露的API调用情况，需要有单独的报表统计，如果发现问题，需要及时响应和处理。

2. 控制故障数量

每周和每月统计故障数量，每个故障都有详细的总结和回顾。故障密集出现的服务凸现出来服务质量有问题。

3. 关注代码质量

每次提测后发现的bug数量，包含bug的分布和等级，更快速反馈团队每位同事的代码质量，控制bug的发生趋势。

2. 项目管理