企业官网建设流程全解析

相亲网站做期货现货贵金属的人,网站后台管理系统栏目位置,汽车可以做哪些广告视频网站,做外贸网站需要注意什么文档总结了前端开发团队在代码规范、质量控制、版本管理和开发流程等方面的一些实践#xff0c;旨在帮助团队建立统一的开发标准#xff0c;提高代码质量和开发效率。1. 前端编码规范管理1.1 统一编码规范1.1.1 命名规范变量命名#xff1a;使用小驼峰命名法#xff08;cam…文档总结了前端开发团队在代码规范、质量控制、版本管理和开发流程等方面的一些实践旨在帮助团队建立统一的开发标准提高代码质量和开发效率。1. 前端编码规范管理1.1 统一编码规范1.1.1 命名规范变量命名使用小驼峰命名法camelCase布尔类型使用 is/has/can 前缀常量使用全大写下划线分隔UPPER_SNAKE_CASE函数命名使用小驼峰命名法动词开头get/set/handle/on/fetch/update/delete/create/validate组件命名使用大驼峰命名法PascalCase文件名与组件名保持一致文件命名组件文件使用 PascalCase工具文件使用 camelCase样式文件使用 kebab-case禁止使用单字母变量名循环除外、拼音命名、无意义命名temp/data1/foo1.1.2 代码格式规范工具配置使用 Prettier 统一格式化ESLint 进行代码检查Stylelint 规范样式代码基本规则2空格缩进单行最大100字符语句结尾使用分号字符串优先使用单引号对象/数组尾部添加逗号代码组织按功能模块划分目录避免循环依赖每个文件只导出一个主要功能1.1.3 注释规范文件头注释必须包含文件功能描述、作者、创建日期/*** file 用户管理服务* author 前端开发团队* date 2035-11-11*/函数注释使用 JSDoc 格式说明参数、返回值、使用示例/*** 获取用户信息* param userId - 员工ID* returns 员工信息对象*/function getUserInfo(userId: string): User {}复杂逻辑注释关键算法、业务规则、临时方案必须添加注释使用 TODO/FIXME 标记待优化代码注释语言统一使用中文专业术语可保留英文1.1.4 日志格式规范日志级别ERROR错误需立即处理、WARN警告潜在问题、INFO重要操作记录、DEBUG调试信息仅开发环境日志格式[时间戳] [级别] [模块] 日志内容 {上下文数据}// 示例console.error([2035-11-11 10:30:15] [ERROR] [UserLogin] 用户登录失败, {userId: 3456789,reason: password error});日志规范错误日志必须包含堆栈信息关键业务操作必须记录敏感信息密码/身份证禁止记录生产环境禁止使用 console.log1.1.5 TypeScript 规范类型定义禁止使用 any优先使用接口interface定义对象类型使用类型别名type定义联合类型类型导出统一在 types/ 目录管理类型定义公共类型集中导出类型转换优先使用 as 进行类型转换避免过度使用非空断言!空值处理使用可选链?.和空值合并??操作符处理可能为空的值减少运行时错误1.1.6 代码复杂度控制函数长度单个函数不超过 80 行圈复杂度不超过 10嵌套层级不超过 4 层代码可读性避免魔法数字使用命名常量代替使用提前返回early return模式减少嵌套层级合理使用解构赋值简化代码使用有意义的变量名避免单字母变量循环变量除外将复杂逻辑拆分为多个小型、专注的函数1.1.7 安全编码规范输入验证所有外部输入用户输入、API 返回数据必须验证使用白名单方式验证数据格式不信任任何外部数据对特殊字符进行适当转义防止 XSS/SQL 注入攻击禁止使用eval()、Function 构造函数、innerHTML优先使用 textContent 或框架提供的安全渲染方法敏感数据处理敏感数据密码、密钥、token禁止前端明文存储使用加密算法保护必要的敏感信息API 请求使用 HTTPS敏感接口添加额外验证机制1.1.8 框架最佳实践Vue 3 项目必须参考 Vue 3 官方风格指南 和 Vue 3 最佳实践React 项目必须参考 React 官方文档最佳实践 和 React TypeScript 最佳实践组件设计遵循单一职责原则合理拆分组件使用 Composition APIVue或 HooksReact性能优化避免不必要的重渲染合理使用 memo/computed/watch懒加载路由和组件1.1.9 依赖管理规范包管理器强制使用 pnpm禁止使用 yarn依赖安装区分 dependencies 和 devDependencies避免安装未使用的依赖版本管理锁定主要依赖版本定期更新依赖并测试兼容性1.2 编码规范工具配置1.2.1 工具配置要求必须安装的工具所有前端项目必须配置以下三个工具缺一不可ESLint代码质量检查发现潜在 Bug 和不规范代码Prettier代码格式化统一代码风格Stylelint样式代码规范检查CSS/SCSS/Less配置文件清单项目根目录必须包含以下配置文件.eslintrc.js / .eslintrc.cjs: ESLint 配置.prettierrc.json: Prettier 配置.stylelintrc.json: Stylelint 配置.eslintignore: ESLint 忽略文件.prettierignore: Prettier 忽略文件1.2.2 工具配置规范ESLint 配置要求推荐使用阿里iceworks/eslint-config-aliAirbnb 规范变体。可继承业界成熟规范二选一团队统一。框架特定配置Vue 项目必须继承 plugin:vue/vue3-recommended typescript-eslint/recommendedReact 项目必须继承 plugin:react/recommended plugin:react-hooks/recommended typescript-eslint/recommended核心规则要求不可豁免禁止使用 any 类型typescript-eslint/no-explicit-any: error圈复杂度不超过 10complexity: [error, 10]嵌套层级不超过 4max-depth: [error, 4]单函数最大行数 80 行max-lines-per-function: [warn, 80]生产环境禁止 console 和 debuggerno-console: [error, { allow: [error] }]Prettier 配置要求参考业界主流配置必须遵循以下统一格式使用分号semi: true使用单引号singleQuote: true每行最大 100 字符printWidth: 100缩进 2 个空格tabWidth: 2对象/数组尾部添加逗号trailingComma: allStylelint 配置要求推荐配置继承 stylelint-config-standard Stylelint 官方推荐继承 stylelint-config-prettier 避免与 Prettier 冲突使用 stylelint-order 插件强制 CSS 属性排序核心规则禁止使用颜色名称必须使用十六进制color-named: never类名使用 BEM 规范或小驼峰命名团队统一禁止使用 !important特殊情况需注释说明1.2.3 工具集成与执行Git Hooks 强制检查参考字节跳动、美团等大厂实践必须安装 husky lint-staged// package.json{lint-staged: {*.{js,jsx,ts,tsx,vue}: [eslint --fix, prettier --write],*.{css,scss,less}: [stylelint --fix, prettier --write]}}IDE 集成配置强制要求团队成员配置 IDE参考阿里、腾讯团队规范安装 ESLint、Prettier、Stylelint 插件开启保存时自动格式化功能使用项目配置文件禁止使用个人自定义配置推荐使用 VS Code 并共享团队 .vscode/settings.jsonCI/CD 流程检查参考大厂 DevOps 实践在持续集成流程中必须执行pnpm run lint # 运行 ESLint 检查pnpm run format # 运行 Prettier 检查pnpm run lint:style # 运行 Stylelint 检查检查失败处理CI/CD 构建失败禁止合并代码必须修复所有 Error 级别问题Warning 级别问题记录在案限期修复48小时内1.2.4 违规处理检查结果分级Error错误必须立即修复阻断代码提交和合并Warning警告建议修复不阻断提交但需在代码审查时说明Off关闭特殊场景可关闭某些规则需注释说明原因豁免机制特殊情况可临时禁用规则但必须添加注释说明// eslint-disable-next-line typescript-eslint/no-explicit-anyconst data: any legacyApiResponse; // 理由对接旧系统类型复杂暂不定义豁免审批要求单文件豁免超过 3 处需技术负责人审批禁止全局关闭规则除非配置文件中明确说明理由1.2.5 配置维护配置更新流程工具配置由技术负责人统一维护配置变更需团队评审通过更新配置后需通知全员并提供迁移指南每半年评审一次配置合理性对标业界最新实践配置版本管理配置文件纳入 Git 版本控制禁止个人随意修改配置不同项目可适度调整但核心规则必须一致定期关注业界动态及时更新规范库版本2. 前端代码质量管理代码质量是项目成功的关键因素直接影响系统的稳定性、可维护性和性能。本章介绍如何通过一系列工具和流程建立完善的代码质量管理体系确保团队交付高质量的前端产品。2.1 代码质量标准与指标体系2.1.1 质量目标我们设定了明确的质量目标作为团队代码质量的基本要求单元测试覆盖率 ≥ 80%代码重复率 5%圈复杂度平均值 10严重漏洞数量 02.1.2 质量指标从多个维度评估代码质量确保全方位控制可靠性Bug密度 5个/千行无严重漏洞和崩溃风险可维护性代码重复率 5%单函数 80行文档完善测试覆盖行覆盖率 ≥ 80%分支覆盖率 ≥ 75%核心业务逻辑 100%性能效率关键操作响应时间 300ms页面加载时间符合性能指标安全性无高危安全漏洞敏感数据得到有效保护2.1.3 质量评级根据综合表现对代码质量进行评级A级优秀所有指标达标测试覆盖率 90%无任何警告或错误B级良好主要指标达标测试覆盖率 80%-90%少量警告但无错误C级合格基本指标达标测试覆盖率 ≥ 80%无严重问题D级不合格存在严重问题如安全漏洞、高Bug率、低测试覆盖率禁止合并2.2 强制代码静态扫描管理SonarQube所有前端项目必须接入 SonarQube 平台。扫描范围覆盖所有源代码排除构建产物和依赖库。扫描范围覆盖所有 src/ 目录下的源代码排除 node_modules/、dist/、build/ 等构建产物包含测试代码*.test.ts、*.spec.ts必检规则Bug 规则空指针引用、资源未关闭、死代码、类型错误漏洞规则XSS 漏洞、敏感数据泄露、不安全的依赖代码异味代码重复、函数过长、圈复杂度过高、嵌套过深安全热点硬编码密钥、弱加密算法、不安全的 HTTP 请求新增代码门禁强制Bug 数量0漏洞数量0代码异味 3个/千行代码测试覆盖率≥ 80%代码重复率 3%整体代码门禁严重 BugBlocker/Critical0 个严重漏洞Blocker/Critical0 个技术债务比率 5%整体覆盖率≥ 80%门禁策略新代码必须 100% 达标A 级标准存量代码允许适当降低标准但严重问题必须为 0核心业务模块执行更严格的门禁标准触发时机代码提交每次 Push 到远程仓库自动触发Pull Request创建 PR/MR 时自动扫描定时扫描每日凌晨 2:00 全量扫描发布前扫描版本发布前必须执行扫描强制执行机制CI/CD 集成代码提交、PR 创建时自动触发扫描门禁阻断未通过质量门禁禁止合并代码自动通知扫描失败自动通知提交者和技术负责人发布前检查版本发布前必须通过扫描扫描结果管理问题处理流程:自动通知扫描完成后自动发送报告给提交者问题分类按严重级别分类标记责任人修复跟踪在项目管理系统中创建任务跟踪修复进度复查验证修复后重新扫描验证扫描报告:报告内容质量门禁状态、问题统计、趋势分析、重点问题列表报告发布自动生成报告并发送给项目负责人报告归档保留所有历史扫描记录支持趋势对比2.3 单元测试管理覆盖率≥80%单元测试是保障代码质量的第一道防线不仅能帮助我们发现潜在问题还能确保代码在重构和迭代过程中保持稳定。良好的单元测试可以显著降低生产环境中的Bug数量提高代码的可维护性。2.3.1 测试覆盖率强制要求行覆盖率≥ 80%分支覆盖率≥ 75%函数覆盖率≥ 85%核心业务逻辑100% 覆盖特殊要求新增代码覆盖率必须 ≥ 80%不允许降低整体覆盖率工具函数、业务逻辑层、数据处理层必须 100% 覆盖UI 组件覆盖率可适当降低至 ≥ 70%2.3.2 测试框架与工具Vue 项目Vitest Vue Test UtilsReact 项目Jest React Testing Library覆盖率工具Istanbul (c8)测试文件命名*.test.ts 或 *.spec.ts2.3.3 测试用例编写规范文件组织每个源文件对应一个测试文件放置在同一目录命名为 [原文件名].test.[ts/js]测试结构使用 AAA 模式Arrange-Act-Assert编写测试Arrange准备设置测试环境和数据Act执行调用被测试函数或组件Assert断言验证结果是否符合预期测试覆盖正常场景确保功能正常工作边界值测试输入的边界条件异常处理验证错误处理机制异步操作正确处理 Promise、回调等依赖管理Mock 所有外部依赖API 调用、第三方库、时间函数使用工具如 Jest 的 mock 功能或 Mock Service Worker测试命名使用描述性名称如 should return correct value when input is valid2.3.4 测试执行与门禁本地执行代码提交前必须通过测试Git Hooks 自动运行CI/CD 执行每次代码提交自动运行全量测试门禁标准所有测试用例通过 覆盖率达标否则禁止合并代码报告生成自动生成覆盖率报告发布到项目看板2.4 代码审查管理代码审查是确保代码质量的重要环节不仅能发现潜在问题还能促进团队知识共享和技术交流。通过严格的代码审查流程可以有效提升整体代码质量和团队编码水平。2.4.1 代码审查强制要求所有代码必须通过审查后方可合并禁止直接提交到主干分支每个 Pull Request 至少 2 人审查其中 1 人为资深开发或技术负责人审查时效一般 PR 2 个工作日内完成紧急 PR 4 小时内完成审查者需确保充分理解需求和实现方案再进行代码审查2.4.2 审查标准代码审查应从以下几个维度全面评估功能性代码实现是否符合需求业务逻辑是否正确代码质量是否符合编码规范可读性、复杂度是否合理安全性是否存在安全漏洞输入验证是否完善测试完整性是否包含单元测试覆盖率是否达标性能合理性是否存在明显性能问题是否有优化空间可维护性代码结构是否清晰命名是否规范注释是否完善2.4.3 审查流程开发人员创建 Pull Request填写变更说明和需求关联自动触发 CI/CD 检查ESLint、SonarQube、单元测试分配审查人员至少 2 人审查人员检查代码并提出意见开发人员修改并回复审查意见所有审查人员批准 CI/CD 通过后合并代码2.4.4 审查结果处理通过所有审查人员批准 自动化检查通过需修改存在问题需修改后重新审查拒绝存在严重问题安全漏洞、严重 Bug、严重违反规范2.5 代码质量门禁与度量2.5.1 质量门禁机制代码必须通过以下所有门禁检查方可合并编码规范检查ESLint/Prettier/Stylelint 全部通过静态扫描检查SonarQube 质量门禁通过无严重 Bug 和漏洞单元测试检查所有测试通过 覆盖率 ≥ 80%代码审查检查至少 2 人审查通过任一门禁未通过CI/CD 构建失败禁止合并代码。2.5.2 代码质量度量指标代码重复率 5%工具SonarQube、jscpd圈复杂度平均 10单函数 ≤ 10工具ESLint complexity函数长度单函数 80 行工具ESLint max-lines-per-function嵌套深度≤ 4 层工具ESLint max-depth技术债务技术债务比率 5%定期还债2.5.3 质量数据统计与通报统计维度按人员、项目、时间统计代码质量指标通报频率每月通报一次通报内容质量门禁通过率、测试覆盖率、代码质量评分、常见问题总结持续改进每季度评审质量标准针对高频问题完善规范和培训3. 前端代码版本控制管理规范的版本控制是现代软件开发的基础对于前端团队尤为重要。良好的版本控制实践能够确保代码变更可追溯、可回滚减少团队协作中的冲突并为持续集成/持续部署提供可靠支持。本章介绍代码提交规范、分支管理策略和发布流程等最佳实践。3.1 代码提交规范Commit Message、变更说明、需求关联3.1.1 Commit Message 格式规范标准格式type(scope): subjectbodyfooterType提交类型feat新功能fixBug 修复docs文档变更style代码格式调整不影响功能refactor重构既不是新功能也不是 Bug 修复perf性能优化test测试相关chore构建工具或辅助工具变更Subject主题简明扼要描述变更内容不超过 50 个字符使用祈使句首字母小写结尾不加句号示例feat(user): 添加用户登录功能Body正文详细描述变更内容、原因和影响可选复杂变更必填Footer页脚必须关联需求关联需求: #需求编号示例关联需求: #12343.1.2 变更说明强制要求每次代码提交必须清楚说明做了什么变更What具体修改了哪些功能或代码为什么变更Why变更的原因和目的影响范围Impact对现有功能的影响禁止的提交信息无意义信息如update、fix、修改过于简单的描述包含敏感信息密码、密钥等3.1.3 需求关联强制要求所有功能类提交feat、fix必须关联需求编号格式关联需求: #需求编号多个需求用逗号分隔需求编号来源项目管理系统或 Issue 编号Git Hooks 自动检查未关联需求禁止提交特殊情况豁免docs、chore 类型可不关联需求3.1.4 提交粒度控制单次提交原则一次提交只做一件事功能完整且可运行提交大小限制单次提交变更文件 ≤ 20 个代码行数 ≤ 1000 行禁止行为多个不相关变更合并提交提交未完成或无法运行的代码提交包含调试代码console.log、debugger提交临时文件或敏感配置3.1.5 提交检查与执行Git Hooks 检查提交前自动检查 Commit Message 格式和需求关联CI/CD 验证代码推送后验证提交信息规范性违规处理提交信息不规范或未关联需求禁止提交需修改后重新提交示例# 正确示例feat(user): 添加用户登录功能- 实现用户名密码登录- 添加验证码验证- 集成登录状态管理关联需求: #1234# 错误示例禁止update # 无意义修改了一些代码 # 过于简单fix bug # 未关联需求