共计 2665 个字符，预计需要花费 7 分钟才能阅读完成。
关键字：代码品质 团队建设 流程优化
一、背景
1. 技术栈
美业技术团队前端对外的业务我的项目的次要编程技术栈是：
2. 团队架构
在构建我的项目的后期，前端对业务我的项目按端来划分人员，各端各司其职，各自积淀。
中期随着产品的根本成型，前端团队人员依照业务畛域划分成了多个子业务组前端，各组负责 4 端中对应模块的业务。
于是，咱们美业团队 20 个前端简直每个人都要保护 4 个不同的编码上下文的我的项目，益处是技术多样性丰盛，然而瓶颈也同样存在，一个人须要领有多端的开发能力，在编码标准和代码格调查看尽可能对立的状况下，因为上述技术体系的差别，咱们还是不得不须要相熟四端的技术架构、开发流程、数据流解决、资产市场、最佳实际。
这是很有挑战的，业务小组之间成立了一个小型的前端技术委员会，来应答这种变动：
- 总结原先的我的项目技术规范，对立宣讲、培训、文档化
- 打造对立标准化的研发流程
- 并且继续吸取新的实际并迭代
3. 代码品质问题
随即，咱们在代码品质上迎来了一些问题：
- 我的项目 Bug 较多，同样的坑不同的人会踩
- 迭代后的代码难保护，包含代码可读性差、复用度低等
- 模块的整体设计也欠缺，扩大能力难以撑持业务倒退。
对代码品质的把控方面，现状流程是：咱们半年要对几端的我的项目代码进行一次整体的 code review。
然而和垃圾回收一样，整体的标记革除占用人员的工夫较长，会影响届时波及人员的业务开发进度。
于是咱们想摸索一种适宜咱们团队和业务倒退的小步快跑模块的 Code Review，尽可能早的从一开始就参加进来，更高频率，加强审查和设计把控，缩小前面返工和带来 Bug 所影响的整体效率。
二、定义需要
有了这样的背景和改良诉求，我发现咱们得从新定义一下咱们做这件事件的目标和价值。
通过思考和探讨，咱们做 Code Review 的外围目标只有两个：
- 从源头把控代码品质和效率
- 对立代码评判规范和认知
- 发现边界问题
- 提出改良倡议
- 共享和迭代个体代码智慧
- 交换计思路和编码实际
- 积淀最佳实际
- 迭代对立标准
同时要做上述现实中的 Code Review，咱们可能不得不面临这些实际过程中会遇到的问题：
- 什么时候 review？
- review 应该关注哪些点？
- review 的评判规范是什么？
- review 除了代码标准和逻辑问题还能看什么？
- 如何发现深层次问题？
- 找谁 review？
- review 的倡议，真的改了吗？
- 小的点会改，大的调整怎么办？
- 通过 review 各方播种了什么？
基于这些诉求和待解决问题，咱们须要对整体的规范和每一次 Code Review 的要害控制点进行细化和量化，于是有了咱们第一版 Code Review 的 SOP（规范作业流程）。
三、V1.0 标准化 SOP
1. 建设标准
1.1 宣讲
宣讲各端对立代码标准和最佳实际、编码准则
1.2 review 小组
成立专门的 code review 小组，小组成员是各端经验丰富的人员
1.3 设定可迭代的代码品质评估维度和规范：
每项 1~5 分，基准分为 3 分，得分在此基础上依据评分点浮动，总评分为各项得分的平均分：
基本面
- 难度大、工作量大，可酌情加分
- 是否合乎根本标准
架构设计
- 如果有设计文档，是否依照设计文档思路来写代码，是可酌情加分
- review 的人是否发现了更好的解决方案
- 代码是否提供了很好的解决思路
代码
- 是否显著反复代码
- 是否正当抽取枚举值，禁止应用“魔法值”
- 是否正当应用已有的组件和办法
- 对已有的、不合理的代码进行重构和优化
- 职责（组件、办法）、概念是否清晰
健壮性
- 边界和异样是否思考齐备
- 在 review 阶段是否发现显著 bug
- 是否思考安全性（xss）
效率
- 是否抽取共用常量到 beauty-const 库，加分
- 是否抽取积淀根底组件和通用业务组件到组件库，加分
1.4 申请格局
code 人在企业微信群发起 Review 申请，对立参考格局，内容包含
- mr 地址
- 产品文档
- UI 稿
- 技术设计
- 效率平台
- 接口文档
1.5 review 要求
- code review 必须在提测前进行
- mr 对立由 feature 分支合到 release 分支
- review 人依据 code review 评分标准 打出各项评分，计算出本次 code review 总评分
- 有须要可在备注中阐明起因，代码相干的备注能够间接在 gitlab 进行
- code 解决反馈的问题
- 要求提测邮件中体现 code review 状况（评分、遗留问题）
- review 记录，定期同步分享
1.6 review 重点
- 倡议 check 代码改变范畴，重点关注外围代码改变的影响
- review 能够针对重点代码进行
- 每项 checklist，如果有不合乎 checklist 内容的，请在前面【评分解释】中具体指出
- 「探讨积淀」内容可包含但不限于：技术设计状况、review 过程中发现的亮点与有余、值得探讨的货色、发现的 bug
- 周会定期同步 review 状况，分享优良代码
2. 单次流程
3. 产出示例
四、V2.0 平台化
1.0 版本在继续的细节迭代，做到了比较满意的标准化作业，然而有几个比拟大的缺点：
- 操作欠缺自动化
- 流程的很多环节显著能够自动化，节俭反复的工作量
- 对流程的把控依赖人，容易执行不到位
- 信息欠缺数字化
- 对 code review 的评分统计须要人工，工作量大
- code review 的总览和数据分析能够撑持更好的判断团队问题和决策晋升整体代码品质的策略
- 流程欠缺可视化
- 所有流程应该是能够大盘总览，单个详情全面的
- 每个 code review 事务的状态是可见的
所以咱们有了把 Code Review 整套流程做成已有的外部前端工具平台中一个模块的想法，以期达到可视化、自动化、数字化的目标。
投入产出比是咱们须要思考的，咱们很笃定。因为尽管这件事件没有间接的业务价值，然而有十分好的品质把控和能力量化的价值，并且有标杆式的团队建设价值，人员成长了，更好地为业务服务。
1. 需要剖析
在实现上述根本需要之后，咱们同时在收集反馈新增了
- code 人可指定 review 人员
- 反对我的项目多端配置
- 首页 review 得分榜排名展现
- 最佳实际对立导出
- 买通关联我的项目平台串联我的项目
2. 技术设计
联合数据库表设计之后，咱们就分工开整了。
3. 产品效果图
五、可继续保障机制
前人种树，前人除了纳凉之外得持续浇灌。流程和机制是死的，咱们得用一些更加有温度的一些策略让它继续能够迭代和倒退继承上来。
- 半年度颁奖：半年咱们会把半年大家的评分问题统计进去，做一次激励，建立标杆，激励大家持续写出更好的代码，也持续的配合 Code Review。
- 专人 Owner：作为一个技术我的项目来继续保护和收集反馈意见迭代，服务小伙伴，为团队建设助力。
- 纳入考核：作为简单的大型 SaaS 我的项目的开发者，代码能力是咱们考核小伙伴业余能力的重要维度。
附带一些半年颁奖的图：
