From 2e6c1724efbe8c21fe2c8753766443656310deb8 Mon Sep 17 00:00:00 2001 From: sit002 Date: Tue, 2 Dec 2025 09:32:15 +0800 Subject: [PATCH] docs: redesign FRONTEND to focus on reflection (3 questions, 10 points) - Simplified from 6 sections to 3 focused questions - Emphasize screenshots (5pts), problem-solving (3pts), reflection (2pts) - Updated rubric to match new structure --- FRONTEND.md | 20 ++++++++-- FRONTEND_GUIDE.md | 99 +++++++++++++++++++++++++---------------------- 2 files changed, 68 insertions(+), 51 deletions(-) diff --git a/FRONTEND.md b/FRONTEND.md index f20c256..08e94f8 100644 --- a/FRONTEND.md +++ b/FRONTEND.md @@ -1,11 +1,23 @@ -# VibeVault 期末大作业报告：前端界面与交互设计 +# 前端开发反思报告 -> 请参考 `FRONTEND_GUIDE.md` 中的写作指导，在此文件中完成你的报告。 -> 建议 800–1500 字。 +> 请参考 `FRONTEND_GUIDE.md` 了解写作要求。建议 600–1200 字。 --- - +## 1. 我的界面展示 + + +## 2. 我遇到的最大挑战 + + + + + +## 3. 如果重新做一遍 + + + + diff --git a/FRONTEND_GUIDE.md b/FRONTEND_GUIDE.md index d3b0587..17dc081 100644 --- a/FRONTEND_GUIDE.md +++ b/FRONTEND_GUIDE.md @@ -1,69 +1,74 @@ -# VibeVault 期末大作业报告：前端界面与交互设计 +# 前端开发反思报告 写作指南 -> 本报告专门用于说明你实现的前端界面与交互设计，建议 800–1500 字。请与 `REPORT.md` 一起提交。 +> **字数**：600–1200 字 +> **形式**：自由叙述，重点展示你的界面和思考 +> **核心**：我们想看到**你的界面设计**和**开发过程中的思考** -## 1. 整体概览与使用流程 +--- -- 简要说明你的前端技术栈（例如：Vite + React + 某 UI 库等），以及项目目录的基本结构。 -- 描述一个典型用户从打开页面到完成核心任务的完整流程，例如： - - 登录 → 查看歌单列表 → 新建歌单 → 向歌单添加歌曲 → 删除歌曲/歌单。 -- 用 2–3 句话概括你的前端设计目标（例如：强调简单易用、突出关键操作、减少页面跳转等）。 +## 写作要求 -## 2. 关键界面截图与说明 +请围绕以下 **三个问题** 展开： -请通过 Markdown 语法在本节插入若干张截图（建议 3–6 张），每张截图下方都要有对应说明。示例： +### 1. 展示你的界面（约 5 分） +**必须包含 3–6 张截图**，每张截图下方要有说明： + +- 截图应覆盖主要功能界面（如歌单列表、创建/编辑、歌曲管理等） +- 每张截图下方用 2–3 句话说明： + - 这个界面是做什么的？ + - 用户在这里可以完成哪些操作？ + - 你在这个界面中设计了哪些交互细节？ + +> 💡 截图是前端报告的核心价值，让读者"看到"你的成果。说明要简洁但信息量充足。 + +**示例格式**： ```markdown -![播放列表总览页面](images/playlists-overview.png) +![歌单列表页面](images/playlists.png) + +这是歌单列表页面，用户可以查看所有歌单。我设计了... ``` -建议覆盖以下场景（可按实际实现情况调整）： +### 2. 你在前端开发中遇到的最大挑战是什么？（约 3 分） -1. **播放列表总览页面** - - 标明页面上最重要的区域（例如：导航栏、歌单列表、主要操作按钮）。 - - 说明用户在该界面可以完成哪些操作，这些操作对应了哪些后端 API（如 `GET /api/playlists`、`POST /api/playlists`）。 +- 描述一个具体的前端问题（如状态管理混乱、组件通信困难、API 对接错误等） +- 说明你的排查和解决过程 +- 从中学到了什么？ -2. **创建/编辑歌单页面或对话框** - - 说明表单字段设计（必填项、可选项）以及你如何做输入校验和错误提示。 +> 💡 好的回答会展现真实的前端开发痛点，而不是"一切顺利"。 -3. **歌曲列表/详情页面** - - 如有实现，说明歌曲列表如何展示、如何添加/删除歌曲。 +### 3. 如果重新做一遍，你会如何改进？（约 2 分） -4. **加载中 / 错误 / 空状态界面** - - 至少展示一种状态；说明你是如何在 UI 层面向用户反馈"正在加载""出现错误""暂无数据"等信息。 +- 回顾你的前端实现，哪些地方可以做得更好？ +- 如果时间充裕，你会优先改进什么？（如性能优化、响应式设计、代码组织等） -> 要求：每张截图下方必须有简短文字说明，让不运行代码的读者也能理解界面意图与交互流程。 +> 💡 诚实地承认不足并提出改进思路，这比假装完美更有价值。 -## 3. 组件划分与状态管理 +--- -- 描述你是如何划分前端组件层次的： - - 哪些是页面级组件？哪些是可复用的通用组件（如按钮、卡片、列表项）？ - - 有无"容器组件 + 展示组件"的区分？ -- 说明状态（state）主要存放在哪里、如何流动： - - 是否使用 React 内部 state、Context、Redux 或其他状态管理方案？ - - 如何避免不必要的重新渲染（如使用 `memo`、拆分组件等）？ -- 如果你有自定义的 hook 或 API 客户端封装，请简单介绍其职责与好处。 +## 评分说明 -## 4. 与后端的对接与解耦 +| 维度 | 分值 | 评分标准 | +|------|------|----------| +| 界面展示 | 5 分 | 截图数量充足(3-6张)、说明清晰、能展现主要功能 | +| 问题解决 | 3 分 | 问题描述具体、解决过程真实、有明确的学习收获 | +| 反思改进 | 2 分 | 能识别不足、提出合理的改进思路 | -- 说明你是如何在前端代码中调用后端 API 的： - - 是否集中封装在某个 `api.ts`/`client.ts` 文件？ - - 错误时如何处理（toast 提示、页面错误组件、控制台日志等）？ -- 解释你的环境配置方案： - - 如使用 `.env` 或 Vite 的环境变量，将后端地址抽离为配置，而不是硬编码在组件内。 -- 如有 CORS 或认证（如携带 JWT）的处理，请在此简要说明请求头、拦截器等设计。 +--- -## 5. 交互细节与用户体验 +## 不需要写的内容 -- 列举 2–3 个你刻意设计的交互细节，例如： - - 提交表单前按钮禁用 / loading 状态切换； - - 删除操作前的确认对话框； - - 成功/失败后的反馈提示（toast/snackbar/banner 等）。 -- 说明你在这些设计中考虑的用户体验因素（如误操作防护、反馈及时性、信息层级清晰度等）。 +- ❌ 技术栈的详细罗列（"我用了 React + Vite..."） +- ❌ 组件结构的详细说明（代码本身会说话） +- ❌ API 调用的详细代码（除非是为了说明某个问题） +- ❌ "我学到了很多"之类的空话 -## 6. 自我评价与改进思路 +--- -- 回顾你的前端实现，简要评价： - - 哪些部分你认为完成得比较满意？（例如结构清晰、交互自然等） - - 哪些部分你觉得可以做得更好？（例如视觉设计、响应式布局、性能优化等） -- 如果有更多时间，你会优先在哪些方面改进这个前端界面？为什么？ +## 示例片段 + +> **不好的写法**： +> "我使用了 React 18，组件分为页面组件和通用组件，状态管理使用了 Context..." +> +> **好的写法**： +> "在实现歌单列表时，我最初把所有数据都放在组件内部 state，导致每次刷新都要重新请求。后来我把数据提升到 Context，不仅减少了重复请求，还能在多个组件间共享状态。这让我理解了状态提升的重要性..."