从桌面到Web – 领域模型的创建
概述
上篇文章《一个人被提拔,不仅仅是能力,而是信任》 中分享了两个点:
- 什么样的工程师,容易被提拔?
- 当被提拔到一线管理者后,你的初衷是什么?
这篇文章分享 一线技术管理者 究竟在管什么事?
咱们从一次完整项目的发布说起,一次完整项目的发布,大概需要经过这几个大的节点:
项目立项 -> 需求评审 -> 视觉稿评审 -> 技术评审 -> 项目启动 -> 开发 -> 联调 -> 测试 -> 发布
有句话是这么说的,通过控制过程质量,来保证结果质量。
那么,一线管理者要做的就是保证每个节点的质量,来保证整个项目的质量。
怎么保证?往下看。
制定规范
技术评审规范
在技术评审前要熟悉产品同学提供的产品文档
、业务流程图
、交互原型图
,反复与产品同学确认,在双方达成一致的情况下,再设计技术方案。
设计技术方案要从 总体 到 局部 ,做到面面俱到。
总体:
- 总体结构图
- 业务流程图
- 时序图
- 核心类图
局部:
- 功能的变更
- 数据库字段的变更
- 业务流程上的变更
- 上下游接口约定的变更
当技术方案确定了,我们就确定了:
- 技术选型(前端/后端框架、日志中间件、消息中间件、数据库…)
- 技术架构(组件与组件之间如何协同工作,如何部署)
- 技术难点预知(明确存在的技术难点,并确定解决方案)
- 性能瓶颈预知(明确可能存在性能瓶颈的地方,并确定应对措施)
- 上下游系统交互(明确在流程中的哪个位置,约定接口文档提供时间、接口联调时间)
- 功能模块划分(任务拆分和分配)
当技术方案确定了,需要输出文档:
-
预估开发工期.xlsx,包括
系统
、模块
、功能
、功能简述
、研发人员
、工时(h)
、预计完成时间
等。功能除了包括正常的开发工作,还要包括
提供接口文档
,接口联调
,研发自测
,文档更新
等。正常的功能开发,拆分成工时的颗粒度最大为 2h,这样的颗粒度能够降低工作的复杂度,使不熟悉相关业务的研发也能够快速上手,比如 2h 就写一个方法。
-
更新项目文档,包括
项目介绍
、产品文档
、业务流程
、系统结构
、接口文档
、数据字段
、外部依赖
、其他
等。H5 + WebGL 展示的3D无人机
这个分类可自定义,主要是为了解决 当人员发生流动 导致 系统交接时产生遗漏的问题。
代码风格规范
虽然代码风格并不影响程序的运行,也不会给程序带来潜在的危险,但是一段好的代码风格,阅读起来能让人赏心悦目,特别是阅读别人的代码,就像自己写的一样。
根据自己使用的语言,制定代码风格规范,可参考语言的相关标准,比如 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 后,审查者要对发现的问题,给予解决方案,同时进行问题记录,便于事后跟踪。
- 审查者不能只在发现问题时提问,遇到不清楚的代码设计和业务,也可以让代码作者进行讲解,便于自己熟悉整个业务和代码设计。
- 期间营造一个讨论问题、解决问题的氛围,不能搞成批判会,这样会影响大家的积极性。
- 事后跟踪
- 对发现的问题,确定修复的难易程度以及影响的范围。
- 对发现的问题,确定修复完成的时间点。
- 对发现的问题,修复后要进行验证。
小结
如上就是一线技术管理者要做的事,这些只是 管事 当中的一小部分。
我猜想,有些读者可能会有这个问题:哪来的时间呀?业务代码天天加班都搞不完,哪些时间搞这些?
这个问题… 首先要承认在大部分的公司中,业务代码是刚需,因为是靠这些业务挣钱的,需要快速上线占领市场的。
当随着公司的发展,技术人员的扩充,规范肯定要慢慢建立起来的,否则就会出现这样那样的问题。
如果公司就几名技术人员,可以先不用搞这些,优先快速发展业务吧。
当各位发现有哪些地方不对 或 不完善的地方,欢迎批评指正。
推荐阅读
Android教程2020 – RecyclerView实际使用