已加入的工程化能力

类别 内容 作用

代码格式

Prettier + format / format:check

统一代码风格

代码质量

ESLint + eslint-config-prettier

避免 ESLint 与 Prettier 冲突

单元测试

Vitest + Testing Library

src/api/kanban.test.ts 示例

Git 钩子

Husky + lint-staged

commit 前自动 format + lint

环境变量

.env.example

文档化配置项

编辑器

.editorconfig

统一缩进、换行

PR 规范

.github/pull_request_template.md

PR 自检清单

CI/CD 增强

CI / Deploy 增加 format:check、test

合并前多一道门禁

新增 npm scripts

pnpm format # 格式化全部代码

pnpm format:check # 检查格式（CI 用）

pnpm typecheck # 仅类型检查

pnpm test # 跑单元测试

pnpm test:watch # 监听模式

pnpm test:coverage # 覆盖率报告

本地启用 Git 钩子

push 后其他人 clone 下来执行：

pnpm install # 自动跑 husky prepare，注册 pre-commit

之后每次 git commit 会自动对暂存文件执行 Prettier + ESLint。

当前工程化架构

后续可继续加强（按需）

  1. E2E 测试：Playwright 测拖拽、创建任务
  2. Commit 规范：commitlint + conventional commits
  3. API 校验：用 Zod 校验请求/响应（项目里已有 zod）
  4. 错误监控：Sentry 接入线上
  5. Branch Protection：main 必须 CI 通过才能合并
  6. Dependabot：自动更新依赖

一、都增加或修改了什么？

1. 代码质量与格式

文件/配置 改动

prettier + .prettierrc / .prettierignore

统一代码格式

eslint.config.js

接入 eslint-config-prettier，避免与 Prettier 规则冲突

全项目源码

跑过一次 pnpm format 统一风格

2. 测试

文件 改动

vitest + vite.config.ts 的 test 配置

单元测试框架

src/test/setup.ts

测试环境初始化

src/api/kanban.test.ts

API 层示例测试（2 个用例）

3. Git 工作流

文件 改动

husky + .husky/pre-commit

commit 前自动检查

lint-staged（package.json）

只检查暂存文件，加快速度

prepare: husky

pnpm install 时自动注册钩子

4. 规范与文档

文件 改动

.editorconfig

编辑器缩进、换行一致

.env.example

环境变量说明

.github/pull_request_template.md

PR 描述模板

.gitignore

忽略 coverage、.env 等

5. 包管理规范

文件 改动

package.json

packageManager、engines.node >= 20

新增 scripts

typecheck、format、test、test:coverage 等

6. CI/CD（工程化的一部分，之前已有）

文件 作用

.github/workflows/ci.yml

PR/push 时：format → lint → test → build

.github/workflows/deploy.yml

合并 main 后部署 GitHub Pages

CI 在工程化阶段的新增项： format:check、test（原先只有 lint + build）。

二、为什么需要工程化？

你这个看板项目已经具备：

  • 前端 + 后端 API
  • 拖拽、持久化
  • CI/CD 自动部署

继续单人开发还勉强够用，但会遇到：

场景 没有工程化时

改完 push

可能线上 build 失败才发现

两人协作

缩进、引号、风格不一致，diff 噪音大

重构 API

不知道有没有改坏，只能手动点页面

新人加入

不知道用什么 Node、怎么配环境

合 PR

缺少统一检查，容易合入有问题的代码

工程化的目标：把「靠人记、靠手测」变成「工具自动兜底」。

三、解决了什么问题？

工程化前工程化后手动测pushCI 可能失败线上出问题pre-commit 本地拦截pushCI 全量检查通过才合并/部署

问题 怎么解决

格式不统一

Prettier + format:check

低级代码错误

ESLint

核心逻辑被改坏

Vitest（目前覆盖 API 层）

坏代码进仓库

Husky pre-commit

坏代码进 main

CI 门禁

环境不一致

.env.example、engines、packageManager

PR 信息缺失

PR 模板

部署前未验证

Deploy workflow 同样跑 test/lint

四、引入了新问题吗？

有，主要是成本和复杂度，属于正常 trade-off：

新问题 说明 应对

commit 变慢

pre-commit 要跑 format + lint

lint-staged 只检查暂存文件；紧急时可 --no-verify（尽量少用）

CI 更严格

format/test 失败会拦合并

本地先跑 pnpm format:check && pnpm test

Prettier 大 diff

首次 format 改了很多文件

已做过一次；之后 diff 会小很多

测试覆盖不足

只有 API 2 个用例，拖拽/UI 未测

后续补组件测试、E2E（Playwright）

Husky 需初始化

新 clone 要 pnpm install 才注册钩子

写在 README 或 onboarding 里

维护成本

多一套依赖要升级

可用 Dependabot 自动提 PR

规则可能过严

例如 shadcn 组件 ESLint 例外

已在 eslint.config.js 里单独处理

没有解决、也不在本轮工程化范围内的：

  • 线上 API 仍要单独部署（Render 等），GitHub Pages 不能跑 Node
  • E2E、性能监控、错误上报（Sentry）尚未接入
  • commit message 规范（commitlint）未加

五、一句话总结

维度 内容

改了什么

格式、测试、Git 钩子、环境文档、CI 增强

为什么

从「个人 demo」升级到「可协作、可持续交付」

解决什么

风格乱、低级错误、坏代码上线、环境不一致

新代价

流程更严、学习成本略增、测试覆盖还需继续补

当前阶段是轻量工程化：适合个人项目和小团队协作。若团队变大，可再补 E2E、commitlint、Branch Protection、Sentry 等。

# react.js # 前端 # 前端框架
Logo
亚马逊云科技技术品牌专区

更多推荐

2026年量化工具选择，要跟着能力基础走

读者应理解，选择工具前要先判断自己的能力基础和当前任务。工具应该帮助自己补上当前最关键的缺口，而不是替代学习顺序本身。

avatar 亚马逊云科技技术品牌专区

近期零基础学量化，先按基础差异拆学习顺序

读者应明白，拆解学习顺序时要先看自己的基础缺口，再决定哪一段需要放慢。不同流程阶段都有不同检查任务，学习路线要能反映这些差异。

avatar 亚马逊云科技技术品牌专区

加州理工 CS367 C 语言系统编程笔记（一）

C语言是一种强大且广泛使用的编程语言，尤其在系统编程领域。本节课我们将学习C语言的基础语法，包括如何编写“Hello, World!”程序、声明变量以及使用基本数据类型。我们将通过实际的代码示例来加深理解。本节课中我们一起学习了C语言的基础语法，包括如何编写和运行一个简单的C程序、声明变量以及使用基本数据类型。我们还介绍了如何使用Shell环境来编译和运行程序。通过对比Java，你可以看到C语言在

avatar 亚马逊云科技技术品牌专区