一线技术管理者究竟在管什么事？

偏执的太偏执、 2022-12-03 09:59 177阅读 0赞

## 概述 ##

这篇文章分享 一线技术管理者 究竟在管什么事？

![format_png][]

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

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

有句话是这么说的，通过控制过程质量，来保证结果质量。

那么，一线管理者要做的就是保证每个节点的质量，来保证整个项目的质量。

怎么保证？

往下看。

## 制定规范 ##

#### 技术评审规范 ####

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

设计技术方案要从 总体 到 局部 ，做到面面俱到。

**总体：**

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

**局部：**

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

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

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

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

*  **预估开发工期.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 后，审查者要对发现的问题，给予解决方案，同时进行问题记录，便于事后跟踪。
     *  审查者不能只在发现问题时提问，遇到不清楚的代码设计和业务，也可以让代码作者进行讲解，便于自己熟悉整个业务和代码设计。
     *  期间营造一个讨论问题、解决问题的氛围，不能搞成批判会，这样会影响大家的积极性。

*  事后跟踪

*   *  对发现的问题，确定修复的难易程度以及影响的范围。
     *  对发现的问题，确定修复完成的时间点。
     *  对发现的问题，修复后要进行验证。

## 小结 ##

如上就是一线技术管理者要做的事，这些只是 管事 当中的一小部分。

我猜想，有些读者可能会有这个问题：

哪来的时间呀？业务代码天天加班都搞不完，哪些时间搞这些？

这个问题... 首先要承认在大部分的公司中，业务代码是刚需，因为是靠这些业务挣钱的，需要快速上线占领市场的。

当随着公司的发展，技术人员的扩充，规范肯定要慢慢建立起来的，否则就会出现这样那样的问题。

如果公司就几名技术人员，可以先不用搞这些，优先快速发展业务吧。

就到这吧。

各位若发现有哪些地方不对 或 不完善的地方，欢迎批评指正。

[format_png]: /images/20221123/b6e9018a0e1e42b7a2bd0ab3da1dad73.png