企业官网建设流程全解析

• 前端
• CMS

代码评审是 Calypso（WordPress.com 的前端应用，仓库根目录可见其核心代码位于 client/ 与 packages/）工程流程中最重要的一环。本文以仓库文档 docs/code-reviews.md 为骨架，结合 docs/merge-checklist.md、docs/CONTRIBUTING.md 与源码中的测试/ESLint 配置，系统讲解 Calypso 代码评审的动机、评审者应关注的八大检查项、评审者与作者的协作心态，以及一套可落地的合并前自测清单，帮助你在参与 Calypso 贡献（或管理自己的大型前端项目）时建立高质量的评审流程。

为什么代码与 UX 评审至关重要

在 Calypso 这样的长生命周期产品中，评审不是"上线前的过场"，而是维持工程质量的核心机制。docs/code-reviews.md 明确指出，评审带来四重价值：

1. 保持代码质量的一致性：让整个代码库保持统一的风格与水准，而不是取决于某个开发者的个人习惯；
2. 分散代码所有权：代码不属于某个个体，而是整个团队的共同资产，评审让更多人理解并接管代码；
3. 帮助每个人持续成长：在分布式协作环境中，评审是低成本、高频次的学习机会；
4. 持续简化设计：每次评审都是一次对"设计是否过于复杂"的重新审视，推动团队不断提炼更简单的抽象，而不是放任复杂度堆积。

注意这里特别强调UX / 设计评审。Calypso 的评审不只盯着逻辑正确性，还要求评审者从界面、交互与可访问性角度审视改动，这一点在下面的"八大检查项"中会具体展开。

一场好的评审应该捕获什么：八大检查项

根据 docs/code-reviews.md，一份合格的评审反馈至少应覆盖以下八个维度：

1. 技术设计问题：架构是否合理、数据流是否清晰、是否引入了不必要的复杂度；
2. UX / 设计问题：交互是否符合直觉、视觉是否一致、是否遵循 Calypso 的响应式与可访问性约定；
3. 可能已存在的组件或方案：Calypso 拥有庞大的共享组件库（如 packages/components）和大量既有工具函数，评审时要避免"重新发明轮子"；
4. 在 Calypso 规模下有问题的 HTML 与 CSS：该项目同时面向桌面、平板与手机，需要警惕在代码库规模下会放大为性能与一致性问题的样式写法；
5. 不必要的复制粘贴：重复代码是后续维护成本的源头，应引导抽取共享抽象；
6. 不符合代码规范的部分：详见 docs/coding-guidelines.md（HTML、CSS/Sass、JavaScript、TypeScript 各有分册，例如 docs/coding-guidelines/javascript.md）；
7. 与代码库其他部分的不一致：随机打开一个文件就应能看懂，是 Calypso 开发者体验的基本要求；
8. Bug：逻辑错误、边界条件、状态持久化缺失等问题。

这八项意味着评审者要同时具备架构视野、产品敏感度和代码洁癖，而不是只做"语法检查"。评审通过后，作者还需对照 docs/merge-checklist.md 完成一系列测试，才能进入合并环节。

评审心态：作者与评审者的双向协作

代码评审对双方都可能是"不舒服"的体验——作者担心被挑刺，评审者担心反馈过重。docs/code-reviews.md 用一个专门小节强调：双方都必须保持积极心态，因为所有人都在共同让 Calypso 与 WordPress 的用户体验变得更好。

结合 docs/CONTRIBUTING.md 的实践，这种心态落在具体行为上包括：

• 任何人都可以评审：即使是 Calypso 新人也被鼓励参与评审、提问与反馈；阅读他人代码是学习新技巧、观察跨模块模式的最佳途径；
• 评审者应分享技巧：在反馈中指出让代码更简单、更可读的具体做法，而不是只说"这样不行"；
• 作者负责推动合入：如果 PR 迟迟无人评审，作者可以主动提及或直接邀请评审人，PR 作者对推动变更落地负有最终责任；
• 每条 PR 都应由非作者的人评审与批准：即使作者有写权限也不例外——"新鲜的眼睛"能发现你沉浸在自己代码中看不见的问题（出处：docs/CONTRIBUTING.md）；
• 寻找评审人的推荐做法：对正在修改的文件执行git blame，查看之前负责该文件提交的开发者，通常就是最合适的评审人选（出处：docs/CONTRIBUTING.md）。

评审的前置工作：小而短的 PR 是评审质量的前提

代码评审的质量，很大程度上取决于提交本身是否"可评审"。docs/git-workflow.md 给出了 Calypso 的硬性约定，评审者与作者都应熟悉：

• 所有变更都从trunk分支切出新分支，分支名采用单斜杠前缀约定：
  • add/{something}：添加全新功能；
  • update/{something}：迭代已有功能；
  • fix/{something}：修复功能缺陷；
  • try/{something}：试验性想法，期望收集反馈。
• 避免分支名中出现多个斜杠，否则会影响 Calypso Live 的自动化测试；
• 分支应小而短命，只有一个 commit 的小分支完全正常；大型功能通过 config 目录下各环境 JSON 的features数组（功能开关）隐藏未完成的部分，而不是靠长分支堆积代码；
• 合并采用Squash and merge策略，历史会被折叠为单个提交，因此冲突时可以使用git rebase trunk或git merge trunk；长讨论分支可本地 rebase 解决冲突后，用git push --force-with-lease（优先于--force，以保护远端提交）更新 PR。

评审者看到一个大而全、横跨多模块的 PR 时，应如 docs/CONTRIBUTING.md 所建议的那样，尽早指出"这个 PR 试图做太多事情"，推动拆分。

评审通过的最后一公里：合并检查清单

code-reviews.md 结尾把读者导向 docs/merge-checklist.md——这份清单既是作者提交 PR 前的自测表，也是评审者在批准前的复核表。完整内容如下：

自动化与基础测试

• 在仓库根目录运行yarn test，确保全部测试通过。从 package.json 的脚本定义可以看到，test实际串行执行test-client、test-packages、test-server、test-build-tools四个子任务，覆盖客户端、共享包、服务端与构建工具四层（脚本"test": "run-s -s test-client test-packages test-server test-build-tools"）。

多站点与多环境验证

• 在多个独立站点以及All My Sites（全部站点视图）下测试，通过站点切换器以及直接访问 URL 两种方式验证功能；
• 显式测试功能预期不适用的场景（例如 Jetpack 站点上不支持的功能）；
• 用Jetpack 托管的站点做显式测试——Calypso 的功能默认都应兼容 Jetpack 站点，除非该功能严格限定为 WordPress.com 专属；
• 测试不同用户权限（admin、editor、author），观察代码在不同角色下的行为。

空初始状态与数据持久化

这是最容易遗漏的一类问题：用户首次登录、清空浏览器历史或换用新浏览器时，通过状态持久化缓存的数据可能并不存在，而代码若未做存在性检查就会抛错。验证方法：

• 开启无痕浏览新会话，或在浏览器开发者工具控制台执行下面命令后刷新页面：

localStorage.clear(); indexedDB.deleteDatabase( 'calypso' );

加载态与空态

• 检查代码如何传达 "loading" 与 "empty" 状态。docs/reactivity.md 给出了 Calypso 的原则：尽量避免加载转圈，充分利用已知信息（例如登录后即可从user.visible_site_count推断站点数量），先按预期形态渲染界面，再用脉冲动画表示数据正在加载，数据到达后响应式更新。

通用 WP.com 提交清单（为 Calypso 调整后）

1. 在手机、平板、桌面上必须响应式可用，触屏设备的交互必须流畅；
2. 在Chrome、Firefox的桌面端（Mac/Win）测试；
3. 收集相关且有用的统计/事件：它们回答什么问题？预期随时间如何变化？
4. 所有字符串必须完全可翻译（不拼接、正确处理复数），并关注长字符串对布局的影响；
5. 涉及的视觉素材必须HiDPI 优化或可缩放；
6. 一切视觉元素既要"内部"一致，也要跨平台一致。

让评审更顺畅的工程化辅助手段

Calypso 把大量评审关注点前置到了自动化工具中，评审者可以据此快速过滤低级问题：

• ESLint：仓库携带 ESLint 配置（见 docs/coding-guidelines/javascript.md），可在根目录运行yarn run lint:js全量检查（package.json 中定义为ESLINT_USE_FLAT_CONFIG=false eslint --ext .js,.jsx,.ts,.tsx,.mjs,.json --cache .），并配合eslint-plugin-wpcalypso插件；规则不适合时鼓励开 issue 讨论，而不是随意用注释屏蔽；
• Git 预提交钩子：bin/pre-commit-hook.js会在每次git commit时自动对改动的 .js/.jsx 文件执行 ESLint，发现违规即阻止提交，把"不符合规范"这一检查项提前到作者本地（详见 docs/coding-guidelines/javascript.md）；
• 风格约束的落地文件：仓库根目录的 .editorconfig（如存在）配合编辑器插件，可自动遵循缩进、行尾空白等约定；trailing-whitespace.md与newline-at-end-of-file.md等细则位于 docs/coding-guidelines 目录。

总结：把评审变成团队的共同成长机制

从 docs/code-reviews.md 可以提炼出 Calypso 评审文化的三个关键词：质量一致、所有权共享、持续成长。对贡献者而言，本文给出了一条完整路径：按 docs/git-workflow.md 用小而短的分支开发 → 借助 ESLint 与预提交钩子提前清理规范问题 → 对照 docs/merge-checklist.md 完成多站点、多权限、空状态与响应式验证 → 以积极心态接受或给出评审反馈 → 经非作者评审批准后 Squash 合入trunk。这套流程同样适用于任何需要多人协作的大型前端仓库——评审的目的从来不是刁难，而是让"我们的代码"比"每个人的代码之和"更好。

• 前端
• CMS