概述
上篇文章《一个人被提拔，不仅仅是能力，而是信任》 中分享了两个点：
什么样的工程师，容易被提拔？
当被提拔到一线管理者后，你的初衷是什么？
这篇文章分享 一线技术管理者 究竟在管什么事？
咱们从一次完整项目的发布说起，一次完整项目的发布，大概需要经过这几个大的节点：
项目立项 -> 需求评审 -> 视觉稿评审 -> 技术评审 -> 项目启动 -> 开发 -> 联调 -> 测试 -> 发布。
有句话是这么说的，通过控制过程质量，来保证结果质量。
那么，一线管理者要做的就是保证每个节点的质量，来保证整个项目的质量。
怎么保证？
往下看。
制定规范
技术评审规范
在技术评审前要熟悉产品同学提供的 产品文档、 业务流程图、 交互原型图，反复与产品同学确认，在双方达成一致的情况下，再设计技术方案。
设计技术方案要从 总体 到 局部 ，做到面面俱到。
总体：
总体结构图
业务流程图
时序图
核心类图
局部：
功能的变更
数据库字段的变更
业务流程上的变更
上下游接口约定的变更
当技术方案确定了，我们就确定了：
技术选型（前端/后端框架、日志中间件、消息中间件、数据库...）
技术架构（组件与组件之间如何协同工作，如何部署）
技术难点预知（明确存在的技术难点，并确定解决方案）
性能瓶颈预知（明确可能存在性能瓶颈的地方，并确定应对措施）
上下游系统交互（明确在流程中的哪个位置，约定接口文档提供时间、接口联调时间）
功能模块划分（任务拆分和分配）
当技术方案确定了，需要输出文档：
预估开发工期.xlsx，包括
系统、模块、功能、功能简述、研发人员、工时(h)、预计完成时间等。功能除了包括正常的开发工作，还要包括
提供接口文档，接口联调，研发自测，文档更新等。正常的功能开发，拆分成工时的颗粒度最大为 2h，这样的颗粒度能够降低工作的复杂度，使不熟悉相关业务的研发也能够快速上手，比如 2h 就写一个方法。
更新项目文档，包括
项目介绍、产品文档、业务流程、系统结构、接口文档、数据字段、外部依赖、其他等。
代码风格规范
虽然代码风格并不影响程序的运行，也不会给程序带来潜在的危险，但是一段好的代码风格，阅读起来能让人赏心悦目，特别是阅读别人的代码，就像自己写的一样。
根据自己使用的语言，制定代码风格规范，可参考语言的相关标准，比如 PHP 有 PSR 。
代码风格规范达成一致后，一定要落实到文档上！
方便其他同事进行 CodeReview 时使用。
代码开发规范
接入 统一可视化日志 平台。
接入 统一配置中心 平台。
接入 统一异常监控 平台。
接入 统一消息中间件 平台。
异常处理规范：直接返回、抛出异常、重试处理、熔断处理、降级处理。
统一 API 规范：HTTP 接口、RPC 接口，Code、Msg、Data 等。
分支开发规范：分支名称规范、热修复规范、上线规范 等。
其他规范，大家可以自行补充 ...
代码管理规范
常用的代码管理工具：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 号，建议在描述中加上。
CodeReview 规范
说实话，由于种种原因，自己实施的并不好。
CodeReview 检查哪些问题？
规范性检查
是否遵循代码开发风格规范、代码开发规范。
是否所有的变量都被正确定义和使用，注释是否准确。
健壮性检查
是否无意中陷入了死循环。
是否存在异常未处理、资源未释放的情况。
是否存在运行时错误（数组边界溢出、除以零的情况）。
重用性检查
-
是否存在相同的方法写了两次，是否可以写成通用类、方法、组件等。
安全性检查
是否存在 SQL注入、XSS、SSRF、CSRF、越权、文件上传 等漏洞。
性能检查
是否存在同步执行太慢，需要转成异步执行的情况。
是否存在未加缓存，频繁链接 DB 的情况。
是否需要使用连接池。
CodeReview 如何执行？
前期准备
制定 CodeReview 规范和标准，这样在审查过程中可以有据可依，有理可循。
确定 CodeReview 审查者、参与者。
实施期
-
在 CodeReview 前，审查者需将 审查内容 及 审查的规范和标准 告知所有参与者和代码作者。 在 CodeReview 时，审查者要进行逐项审查，不能因为时间不足等因素一扫而过。
在 CodeReview 后，审查者要对发现的问题，给予解决方案，同时进行问题记录，便于事后跟踪。
审查者不能只在发现问题时提问，遇到不清楚的代码设计和业务，也可以让代码作者进行讲解，便于自己熟悉整个业务和代码设计。
期间营造一个讨论问题、解决问题的氛围，不能搞成批判会，这样会影响大家的积极性。
事后跟踪
-
对发现的问题，确定修复的难易程度以及影响的范围。 对发现的问题，确定修复完成的时间点。
对发现的问题，修复后要进行验证。
小结
如上就是一线技术管理者要做的事，这些只是 管事 当中的一小部分。
我猜想，有些读者可能会有这个问题：
哪来的时间呀？业务代码天天加班都搞不完，哪些时间搞这些？
这个问题... 首先要承认在大部分的公司中，业务代码是刚需，因为是靠这些业务挣钱的，需要快速上线占领市场的。
当随着公司的发展，技术人员的扩充，规范肯定要慢慢建立起来的，否则就会出现这样那样的问题。
如果公司就几名技术人员，可以先不用搞这些，优先快速发展业务吧。
就到这吧。
各位若发现有哪些地方不对 或 不完善的地方，欢迎批评指正。
本文分享自微信公众号 - 测试开发社区（TestDevHome）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/4580821/blog/4364236