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

概述

上篇文章《一我的被提拔，不只仅是能力，而是信任》 中分享了两个点：

1. 什么样的工程师，容易被提拔？
2. 当被提拔到一线管理者后，你的初衷是什么？

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

[m_2_1]

我们从一次完整项目的发布提及，一次完整项目的发布，大概须要通过这几个大的节点：

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

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

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

怎么保证？往下看。

制定规范

技术评审规范

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

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

整体：

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

局部：

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

当技术方案肯定了，咱们就肯定了：

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

当技术方案肯定了，须要输出文档：

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

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

  正常的功能开发，拆分红工时的颗粒度最大为 2h，这样的颗粒度可以下降工做的复杂度，使不熟悉相关业务的研发也可以快速上手，好比 2h 就写一个方法。

• 更新项目文档，包括 项目介绍、产品文档、业务流程、系统结构、接口文档、数据字段、外部依赖、其余 等。

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

代码风格规范

虽然代码风格并不影响程序的运行，也不会给程序带来潜在的危险，可是一段好的代码风格，阅读起来能让人赏心悦目，特别是阅读别人的代码，就像本身写的同样。

根据本身使用的语言，制定代码风格规范，可参考语言的相关标准，好比 PHP 有 PSR 。

代码风格规范达成一致后，必定要落实到文档上！！！方便其余同事进行 CodeReview 时使用。

代码开发规范

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

代码管理规范

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

工具的使用，你们都知道，就很少说了，约定一些基础的规范。

• 不要提交本身的用户配置，好比 IDE 配置。
• 不要提交不能经过编译的代码。
• 要早提交、常提交，提交以前要先更新。
• 提交信息必定要认真填写，参考以下规范。

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

type 表示 动做类型，可分为：

1. fix：修复 xxx Bug
2. feat：新增 xxx 功能
3. test：调试 xxx 功能
4. style：变动 xxx 代码格式或注释
5. docs：变动 xxx 文档
6. refactor：重构 xxx 功能或方法

scope 表示 影响范围，可分为：模块、类库、方法等。

subject 表示 简短描述，最好不要超过 60 个字，若是有相关 Bug 的 Jira 号，建议在描述中加上。

CodeReview 规范

说实话，因为种种缘由，本身实施的并很差。

CodeReview 检查哪些问题？

• 规范性检查

  • 是否遵循代码开发风格规范、代码开发规范。
  • 是否全部的变量都被正肯定义和使用，注释是否准确。

• 健壮性检查

  • 是否无心中陷入了死循环。
  • 是否存在异常未处理、资源未释放的状况。
  • 是否存在运行时错误（数组边界溢出、除以零的状况）。

• 重用性检查

  • 是否存在相同的方法写了两次，是否能够写成通用类、方法、组件等。

• 安全性检查

  • 是否存在 SQL注入、XSS、SSRF、CSRF、越权、文件上传 等漏洞。

• 性能检查

  • 是否存在同步执行太慢，须要转成异步执行的状况。
  • 是否存在未加缓存，频繁连接 DB 的状况。
  • 是否须要使用链接池。

CodeReview 如何执行？

• 前期准备

  • 制定 CodeReview 规范和标准，这样在审查过程当中能够有据可依，有理可循。
  • 肯定 CodeReview 审查者、参与者。

• 实施期

  • 在 CodeReview 前，审查者需将 审查内容 及 审查的规范和标准 告知全部参与者和代码做者。
  • 在 CodeReview 时，审查者要进行逐项审查，不能由于时间不足等因素一扫而过。
  • 在 CodeReview 后，审查者要对发现的问题，给予解决方案，同时进行问题记录，便于过后跟踪。
  • 审查者不能只在发现问题时提问，遇到不清楚的代码设计和业务，也可让代码做者进行讲解，便于本身熟悉整个业务和代码设计。
  • 期间营造一个讨论问题、解决问题的氛围，不能搞成批判会，这样会影响你们的积极性。

• 过后跟踪

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

小结

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

我猜测，有些读者可能会有这个问题：哪来的时间呀？业务代码每天加班都搞不完，哪些时间搞这些？

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

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

若是公司就几名技术人员，能够先不用搞这些，优先快速发展业务吧。

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

推荐阅读

• 一我的被提拔，不只仅是能力，而是信任