本文目录

[[toc]]

前端组件规范

核心原则

  • 单一职责: 组件职责单一且明确。
  • 数据驱动: 对于组件的控制优先使用数据驱动，实在难以使用数据控制的再考虑使用 ref 调用组件方法。
  • 组件颗粒度: 代码量一般在 300 行内，超过 500 行需要考虑拆分逻辑或者重构。

组件设计原则

组件分类

  • 基础组件: 无外部依赖，如：纯样式组件
  • 复合组件: 组合基础组件，含简单交互逻辑，如：表单组合/表格分页
  • 业务组件: 绑定特定业务场景，可含状态管理，如： 订单流程/用户信息卡片等

组件通信

  • Props 传递: 优先使用 props 进行父子组件通信
  • 事件通信: 使用事件机制进行组件间通信
  • 状态管理: 复杂状态使用状态管理工具（如 Redux、Vuex）
  • Context: 跨层级组件通信使用 Context

组件复用

  • 抽象公共逻辑: 将可复用的逻辑抽离为 hooks 或工具函数
  • 组件封装: 将通用 UI 封装为基础组件
  • 避免重复代码: 使用高阶组件或组合式 API 复用逻辑

命名规范

文件命名

  • 组件文件使用 PascalCase（如 UserProfile.vue）
  • 工具类文件使用 camelCase（如 formatDate.ts）
  • 样式文件与组件同名（如 UserProfile.less）

组件命名

  • 组件名使用 PascalCase
  • 基础组件以特定前缀开头（如 BaseButton、BaseInput）
  • 业务组件以功能命名（如 UserList、OrderForm）

变量命名

  • 变量使用 camelCase
  • 常量使用 UPPER_SNAKE_CASE
  • 布尔类型变量以 is、has、can 等开头

样式规范

CSS 命名

  • 使用 BEM 命名规范
  • 避免样式污染，默认使用 scoped

样式组织

  • 按组件划分样式文件
  • 提取公共样式
  • 使用 CSS 变量管理主题

性能优化

渲染优化

  • 避免不必要的重渲染
  • 使用虚拟列表处理长列表

加载优化

  • 组件懒加载
  • 资源预加载
  • 合理使用 Suspense

测试规范

测试类型

  • 单元测试：测试组件逻辑

测试原则

  • 测试关键业务逻辑
  • 保持测试代码简洁
  • 定期更新测试用例

技术规划

五看

  • 看行业/趋势: 研究所在行业的整体发展趋势、技术进步、政策法规变化等。
  • 看对手/竞争: 分析当前市场竞争格局、竞争对手的优势和弱点，以及合作的可能性。看你行业里面最牛逼的那几家，学习别人的好处，看清别人的未来，对标学习。
  • 看市场/客户: 深入理解市场需求、消费者行为、细分市场机会及潜在客户需求的变化。 客户是谁？ 客户买什么？ 需求是什么？
  • 看自身: 评估公司自身的资源能力、核心竞争力、组织架构、企业文化等方面的优势和不足。
  • 看机会: 识别新的商业机会、蓝海市场或技术创新带来的战略机遇。

三定

  • 定策略: 根据"五看"的结果，明确企业在特定时期内的业务策略，包括产品定位、市场定位、差异化策略等。
  • 定战略: 在深入了解内外部环境的基础上，制定中长期发展战略，包括但不限于目标市场选择、增长路径设计、商业模式创新等。
  • 定规划: 将战略转化为具体的执行计划和行动方案，设定短期、中期和长期的目标，制定实施步骤和资源配置计划。

根因分析法（ Root Cause Analysis, RCA ）

根因分析法是一种用于深入探索问题本质原因的系统化方法，广泛应用于质量管理、项目管理及事故调查等多个领域。其核心目标是找到问题的根本原因，并采取有效措施防止问题再次发生。

分析步骤如下:

  1. 定义问题: 明确阐述问题的具体内容，包括问题发生的时间、地点、影响范围及其严重程度等关键信息。
  2. 数据收集与信息整理: 通过观察、记录、访谈、查阅文件等多种途径获取与问题相关的一切数据和事实。
  3. 原因层次分析:
    • 直接原因分析: 识别导致问题直接发生的表面原因。
    • 根本原因分析: 进一步挖掘深层次的原因，这可能涉及组织文化、政策、流程、人员技能、设备工具等方面。
  4. 运用分析工具: 常见工具有以下几种
    • 5W1H 分析法（What、Where、When、Who、Why、How）
    • 鱼骨图（Cause and Effect Diagram / Fishbone Diagram）
    • 连续五次追问为什么的"五个为什么"（Five Whys）以及逻辑树分析（Logic Tree）
  5. 验证根本原因: 确认所找的根本原因是否准确可靠，可通过复现问题场景或查找其他证据进行验证。
  6. 制定解决方案: 针对识别出的根本原因制定相应的改进措施，确保这些措施能够从源头上解决问题，而不仅仅是处理表面现象。
  7. 实施与跟踪: 执行改进措施，并持续监控效果，以验证措施是否有效防止了问题的重复出现，必要时调整优化方案。
  8. 持续改进: 将根因分析的结果作为组织学习与改进过程的一部分，推动整体业务性能和质量的持续提升。

SWOT 分析

优劣危机

  • 优: 内部优势
  • 劣: 内部劣势
  • 危: 外部危险
  • 机: 外部机遇

用停御成

  • 用: 善用优势
  • 停: 停缓劣势
  • 御: 抵御危险
  • 成: 成就机遇

前端质量保障方案

三层四面

事前（开发阶段）事中（集成阶段）事后（线上阶段）
基建
  • 测试服务（泳道、云真机）
  • 技术架构标准化
  • 供应链质量
  • 通用高并发问题解决方案
  • 日志服务
  • 分支管理
  • 构建部署
  • 静态扫描（checklist）
  • 监控（报错、体验、舆情）
  • 定位系统
  • 指标巡检
  • 安全
测试
  • 流程方法标准化
  • 用例管理
  • 接口测试
  • 自动化测试
  • 回归测试
  • 众测
风控
  • 封禁期
  • 灰度、渐进式
  • 备份、降级
  • 开关
管理
  • 技术方案
  • SOP
  • 需求管理
  • Code Review
  • 研发过程度量
  • 线上故障管理

开发阶段

测试服务

测试作为质量保障的基础手段，其效率和准确性在很大程度上依赖于完善的测试环境、强大的测试工具以及高效的测试服务。

  • 对于兼容性测试: 先进的工具可实现一键模拟多台设备渲染页面，并通过截图比对自动生成报告，显著提高问题定位速度，如能自动标识出存在问题的机型，则极大地 简化了兼容性问题的发现过程。
  • 自动化测试方面: 便捷的脚本录制功能使得非程序员也能快速创建自动化测试用例，无需手动编写代码来驱动测试流程。这种特性如网易 Airtest 等工具所具备的，可以极大 提升回归测试的覆盖面和执行效率 ， 减轻人工测试负担，确保产品质量得到持续有效的验证。

技术架构标准化

技术架构标准化是基于最佳实践的原则，其核心目标在于提升开发效率和保障开发质量。关键机制：

  • 预防与消除潜在问题: 技术架构标准化通过对设计的硬性约束，能够有效防止或减少因人为错误导致的故障隐患，通过 预先设定的技术规范和框架约束 ，使得开发者在遵循标准的过程中降低出错概率。
  • 复杂度控制: 面对需求不断增长和技术规模扩大带来的复杂度挑战，技术架构标准化通过 采用框架 、 组件化 以及 MVVM 等架构模式来分解和简化系统结构，从而有效地管理并降低实现层面的复杂度。
  • 团队协作优化: 通过 约束开发模式、统一团队开发风格 ，技术架构标准化有助于保持代码的一致性和可维护性，避免个人风格差异造成的额外复杂度，促进团队成员之间的高效协同工作，进一步提升整体项目的质量和稳定性。

外部依赖质量管理

通用的依赖一般来说有：CDN、网络、容器、接口、基础框架/库、sdk（埋点、监控之类的）、打包工具等等。关键要形成两点判断：

  1. 依赖是否可靠: 比如出问题了能否找到维护方、核心的依赖如果崩溃有没有降级兜底方案等

  2. 依赖是否彻底解耦: 比如某些配置不应该跨项目或者跨团队存在，否则一定会相互中伤

    • CDN: 主要问题是节点故障
    • 网络: 主要问题是劫持，资源被劫持后，响应没有带跨域 Access-Control-Allow-Origin: *这个头，就会导致资源因跨域而被浏览器拒绝执行，页面就挂了
    • 容器: Webview 可能出现各种问题
    • 接口: 接口异常监控，还需要考虑对接口的调用量进行监控
    • 基础框架/库: 原则上需要锁定版本，不要完全指望开发者遵循 semver 版本语义，任何变动都可能产生故障。
    • sdk: 引入的 sdk 也是可能出问题的。像监控类的 sdk 必须先加载，且必须是同步加载，可考虑内联，避免网络加载失败
    • 打包工具: 检测 es6 代码，检测循环引用，检测重复包等

日志

  • 需要记日志场景: 统计某个指标、排查问题、监控异常
  • 需要记日志的地方: 主动监控（接口、业务异常等），被动监控（网络/资源时延与成功率、页面性能、js error）

技术方案

技术方案都是后端主导，毕竟业务逻辑主要在后端，前端只是负责展示，而且后端涉及库表、缓存、接口、系统调用关系、逻辑流等，很容易画出一堆图来讲，前端要是没个明确指南，技术方案往往不知道写啥

技术方案主要目的有三个：

  • 提前想清楚关键问题: 比如：影响范围、依赖资源、数据来源、核心逻辑、接口方案、兜底方案、监控方案、测试方案、上线方案
  • 排期的依据: 大型需求只有经过拆解才可能给出准确排期
  • 同行把关: 从团队管理角度，一般在各个细分领域有至少主备两人（或多人）专门负责。评审时视情况将相关的负责人拉进来，协助扫雷

SOP

SOP （标准操作程序）是一种流程标准化的行动指南， SOP 应该达到的标准是任何新人看着文档就能一步步完成整个操作

需求管理

需求管理可以做的事情包括：

  • 质疑必要性、合理性: 凡事先想为什么。无明确收益或收益不可衡量的拍脑袋式的需求，拒绝执行或优先级往后排（有些事拖一拖往往有转变）
  • 大需求、探索性需求可考虑分期开展
  • 明确要做的事情: 符合问题与目标所定义的范畴
  • 需求变更不能轻易接受: 哪怕是需要接受的合理变更，也应该给需求方施加一点压力
  • 对产品本人需要有判断: 比如刚加入团队，又提比较大的需求，大概率会出现较多的需求变更

集成阶段

分支管理

  • 禁止本地直接 push master，禁止远程直接修改 master
  • 合并 master 强制走 pr，必须有 approve 才能合并
  • 锁定线上环境发布的分支，避免其他分支因误操作被发上线

封禁期 / 灰度 / 渐进式

  • 封禁期是一种风控手段，避免节假日上线，除了可能因用户量增加放大故障的后果，还有就是避免因休假无人修 bug
  • 灰度发布主要是避免一次性上线，导致潜在故障也跟着瞬间全量
  • 渐进式是一种基础理念，不仅体现在发布过程，也体现在日常做事中

Code Review

需要 Review 的内容：

  • 代码质量（前置校验、边界条件、复用、技术实现、加日志…）
  • 代码可读性（指出看不懂的地方、改命名、加注释…）
  • 发现问题（技术实现的问题、业务逻辑的问题…）

线上阶段

监控

监控系统的责任，是尽快发现问题。

  • 根据监控的手段
    • 被动监控: window.onerror 被动监听
    • 主动监控: try catch 主动上报
  • 根据监控的对象
    • 体验监控
    • js 报错监控
    • 供应链监控

参考资料:

备份、降级、开关

各个重点功能都必须考虑备份方案，出问题了可自动降级，或通过开关控制，关闭入口

故障管理

  • 明确问题
  • 及时止损
  • 定位原因
  • 复盘总结