大家好,我是文档梅。
很多团队在做前端工程化时,把精力全放在了 Webpack / Vite 配置、CI / CD 流程、Monorepo 架构上,却往往忽略了一个核心基础设施——文档架构。
结果往往是:代码重构了三轮,README 还是两年前的样子;新同学配环境配了三天,发现文档里的 Node.js 版本要求早就过时了。
今天我们就把话讲明白:如何把文档当成前端工程的一等公民,搭建一套可维护、能自动化的前端文档架构?
一、 先做顶层设计:前端文档如何分层?
写文档最忌讳“眉毛胡子一把抓”。一个成熟的前端工程,文档应该按受众和场景切分成四个层次:
- 上手文档(Onboarding & Quick Start):
- 受众:新入职同学、外部协作方。
- 内容:环境依赖、启动步骤、常见报错 FAQ。
- 架构与规范文档(Architecture & Guide):
- 受众:核心开发、架构师。
- 内容:目录结构规范、状态管理方案、数据流转图、路由守卫逻辑。
- 组件与 API 参考(Components & API Reference):
- 受众:日常业务开发者。
- 内容:UI 组件 Props / Events 说明、通用 Hooks 用法、工具函数入参及返回值。
- 变更日志(Changelog & ADR):
- 受众:全员。
- 内容:版本发布记录、重大架构决策记录(Architecture Decision Record)。
二、 目录结构:推荐的“代码即文档”布局
在 Monorepo 或标准前端项目中,建议采用 同域存放(Colocation) 的原则,让组件代码与文档待在一起,降低维护阻力。
推荐的目录结构示意:
text
my-frontend-project/
├── docs/ # 全局与架构文档(通常配合 VitePress / Docusaurus)
│ ├── .vitepress/
│ ├── guide/
│ │ ├── getting-started.md # 上手指南
│ │ └── architecture.md # 架构设计
│ └── adr/ # 架构决策记录
│ └── 001-use-zustand.md
├── packages/
│ └── ui-components/ # 组件库
│ └── src/
│ └── Button/
│ ├── Button.tsx
│ ├── Button.test.tsx
│ ├── Button.stories.tsx # 交互式文档 (Storybook)
│ └── README.md # 针对该组件的补充说明
└── package.json
三、 自动化生成:让 TypeScript 为文档打工
人工手写 API 表格是最容易过期的。在前端工程中,我们完全可以通过 TypeScript 类型定义结合工具(如 TypeDoc 或 react-docgen / vue-docgen-api)自动提取文档。
示例:基于 JSDoc 注释的 TypeScript 组件
tsx
import React from 'react';
export interface ButtonProps {
/**
* 按钮展示变体类型
* @default 'primary'
*/
variant?: 'primary' | 'secondary' | 'danger';
/**
* 按钮内部文本或子元素
*/
children: React.ReactNode;
/**
* 是否处于加载状态
* @default false
*/
loading?: boolean;
/**
* 点击事件回调
*/
onClick?: (event: React.MouseEvent<HTMLButtonElement>) => void;
}
export const Button: React.FC<ButtonProps> = ({
variant = 'primary',
children,
loading = false,
onClick,
}) => {
return (
<button className={`btn btn-${variant}`} onClick={onClick} disabled={loading}>
{loading ? 'Loading...' : children}
</button>
);
};
工程化配合: 通过静态分析工具,上述代码里的注释会被自动转译为如下 Markdown 表格,直接注入到文档站点中:
| 属性名 | 说明 | 类型 | 默认值 |
|---|---|---|---|
variant | 按钮展示变体类型 | 'primary' | 'secondary' | 'danger' | 'primary' |
children | 按钮内部文本或子元素 | React.ReactNode | - |
loading | 是否处于加载状态 | boolean | false |
onClick | 点击事件回调 | (event: MouseEvent) => void | - |
四、 CI / CD 集成:文档也是流水线的一部分
文档写完不能只躺在本地,必须融入持续集成(CI)流程。
步骤拆解:
- 死链检查(Broken Link Check): 在 PR 阶段检查 Markdown 中的内部引用链接是否失效。
- 文档构建与 Lint: 确保文档中内嵌的代码块语法正确、类型无误。
- 自动化部署(Preview Deploy): 每次提 PR 时生成预览链接,方便 Code Review 时直接对照看效果。
示例:GitHub Actions 流程配置片段
yaml
name: Build and Check Docs
on:
pull_request:
paths:
- 'docs/**'
- 'packages/**/*.md'
- 'packages/**/*.stories.tsx'
jobs:
docs-check:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: 20
cache: 'pnpm'
- name: Install Dependencies
run: pnpm install
- name: Check Broken Links & Lint Docs
run: pnpm run docs:lint
- name: Build Docs Site
run: pnpm run docs:build
五、 梅姐的三条落地建议
最后,分享 3 条保证团队文档能够长期维持生命力的具体建议:
- PR 审查卡点: 功能变更如果涉及架构或对外组件 API 的调整,PR 中必须同时包含对应文档的更新,否则不予 Merge。
- 把文档算进排期: 评估需求工时时,明确留出 10% - 15% 的“文档与示例开发时间”,不要指望上线后再“找时间补”。
- 工具选型越轻越好: 业务项目优先选 VitePress(Vue 生态)或 Docusaurus(React 生态),交互示例优先选 Storybook。开箱即用,不要过度封装文档基建。
总结: 优秀的前端工程化不仅关乎构建速度和运行性能,也关乎团队的协作效率。把文档结构化、自动化、流程化,才是让工程长期可持续发展的正解。
许可协议:CC BY-NC 4.0
更新于 3 小时前
觉得文章有帮助?点个赞吧!
0 条评论


