docs: redesign REPORT to focus on reflection (3 questions, 10 points)
This commit is contained in:
parent
9de97bddf1
commit
c17e6be1e6
21
REPORT.md
21
REPORT.md
@ -1,10 +1,23 @@
|
||||
# VibeVault 期末大作业报告:后端与系统设计
|
||||
# 后端开发反思报告
|
||||
|
||||
> 请参考 `REPORT_GUIDE.md` 中的写作指导,在此文件中完成你的报告。
|
||||
> 建议 1500–3000 字,使用中文。
|
||||
> 请参考 `REPORT_GUIDE.md` 了解写作要求。建议 800–1500 字。
|
||||
|
||||
---
|
||||
|
||||
<!-- 请在下方开始撰写你的报告 -->
|
||||
## 1. 我遇到的最大挑战
|
||||
|
||||
<!-- 描述一个具体的问题、你的排查过程、以及最终如何解决 -->
|
||||
|
||||
|
||||
|
||||
## 2. 如果重新做一遍
|
||||
|
||||
<!-- 回顾你的设计决策,哪些地方可以做得更好? -->
|
||||
|
||||
|
||||
|
||||
## 3. AI 协同开发经验
|
||||
|
||||
<!-- 举 1-2 个具体例子,分享 AI 帮助你和误导你的经历 -->
|
||||
|
||||
|
||||
|
||||
@ -1,46 +1,64 @@
|
||||
# VibeVault 期末大作业报告:后端与系统设计
|
||||
# 后端开发反思报告 写作指南
|
||||
|
||||
> 请使用中文完成报告,建议 1500–3000 字。你可以使用任意 Markdown 编辑工具。
|
||||
> **字数**:800–1500 字
|
||||
> **形式**:自由叙述,不必拘泥于固定格式
|
||||
> **核心**:我们想听到的是**你的思考**,而非代码的复述
|
||||
|
||||
## 1. 系统概览与架构设计
|
||||
---
|
||||
|
||||
- 简要描述你的系统功能(例如:歌单管理、歌曲管理、用户管理等)。
|
||||
- 画出或文字说明你的分层结构(Controller / Service / Repository),并说明每一层的主要职责。
|
||||
- 解释你如何在代码中体现"高内聚、低耦合"和"依赖倒置"。
|
||||
## 写作要求
|
||||
|
||||
## 2. 数据建模与持久化
|
||||
请围绕以下 **三个问题** 展开你的反思:
|
||||
|
||||
- 描述你的核心实体(如 `User`, `Playlist`, `Song`)及它们之间的关系(如 One-to-Many, Many-to-One)。
|
||||
- 解释你选择的主键策略(如 `@GeneratedValue`)和约束(如唯一性、非空约束)的设计理由。
|
||||
- 如果你对数据库结构做了扩展或修改,请在此详细说明。
|
||||
### 1. 你遇到的最大挑战是什么?你是如何解决的?(约 4 分)
|
||||
|
||||
## 3. 业务逻辑与事务
|
||||
- 描述一个让你卡住、困惑或反复调试的具体问题
|
||||
- 说明你的排查过程:尝试了哪些方法?走了哪些弯路?
|
||||
- 最终是如何解决的?从中学到了什么?
|
||||
|
||||
- 选择 1–2 个你认为最关键的业务用例(例如"批量向歌单添加歌曲并保持原子性"),描述其业务流程。
|
||||
- 说明你在这些用例中如何使用事务(如 `@Transactional`),以及这样设计的原因。
|
||||
- 如果你实现了高级查询(如模糊搜索、复制歌单),请说明实现方式与性能考虑。
|
||||
> 💡 好的回答会展现真实的问题解决过程,而不是"一切顺利"的流水账。
|
||||
|
||||
## 4. 安全与访问控制
|
||||
### 2. 如果重新做一遍,你会有什么不同的设计决策?(约 3 分)
|
||||
|
||||
- 描述你的认证方案(如 JWT),以及如何将用户身份传递给业务层。
|
||||
- 说明你的授权策略:谁可以删除/修改谁的歌单?你是如何在代码中实现"所有权检查"的?
|
||||
- 如果你实现了更多安全特性(如密码加密、角色/权限),请在此展开。
|
||||
- 回顾你的代码架构、数据模型或实现方式
|
||||
- 哪些地方你现在觉得可以做得更好?
|
||||
- 如果时间充裕,你会如何改进?
|
||||
|
||||
## 5. 测试策略与质量保障
|
||||
> 💡 这个问题考察的是你的反思能力和技术判断力,承认不足比假装完美更有价值。
|
||||
|
||||
- 概述你为本项目编写的测试类型(单元测试、集成测试等)及覆盖的主要场景。
|
||||
- 列举 1–2 个你通过测试发现并修复的典型 bug,说明问题成因和修复思路。
|
||||
- 反思:如果以后需要继续扩展本项目,你认为当前的测试体系是否足以支撑频繁重构?为什么?
|
||||
### 3. 你如何使用 AI 辅助开发?有什么经验教训?(约 3 分)
|
||||
|
||||
## 6. AI 协同开发反思
|
||||
- 举 1-2 个具体例子:你问了什么?AI 给了什么回答?
|
||||
- 哪些 AI 建议是有用的?哪些是错误或需要修改的?
|
||||
- 你学到了什么关于"如何正确使用 AI"的经验?
|
||||
|
||||
- 具体描述 2–3 个你在项目中使用大语言模型(如 ChatGPT、Cursor 等)协助开发的案例:
|
||||
- 你给出了什么样的 Prompt?
|
||||
- 得到的回答中哪些部分是直接采用的?哪些部分你进行了修改或重写?
|
||||
- 分析:在本项目中,AI 对你最大的帮助是什么?最容易"误导"你的地方又是什么?
|
||||
- 总结:你会如何在未来的工程实践中规范、有效地使用 AI 作为编码伙伴?
|
||||
> 💡 诚实地分享 AI 帮助你的地方和误导你的地方,这比"AI 很有用"的泛泛之谈更有价值。
|
||||
|
||||
## 7. 总结与自我评估
|
||||
---
|
||||
|
||||
- 总结你在本项目中最重要的三点收获(可以是技术、思维方式或协作方式)。
|
||||
- 按照课程要求的大作业评分维度(功能、架构、测试、安全、文档),给自己一个客观的自评分,并简要说明理由。
|
||||
## 评分说明
|
||||
|
||||
| 维度 | 分值 | 评分标准 |
|
||||
|------|------|----------|
|
||||
| 问题解决 | 4 分 | 问题描述具体、解决过程真实、有明确的学习收获 |
|
||||
| 反思深度 | 3 分 | 能识别自己代码的不足、提出合理的改进思路 |
|
||||
| AI 使用 | 3 分 | 有具体案例、能辨别 AI 输出的优劣、有实用的经验总结 |
|
||||
|
||||
---
|
||||
|
||||
## 不需要写的内容
|
||||
|
||||
- ❌ 代码结构的详细说明(代码本身会说话)
|
||||
- ❌ API 端点的罗列(README 已经有了)
|
||||
- ❌ "我学到了很多"之类的空话
|
||||
- ❌ 复制粘贴的技术概念解释
|
||||
|
||||
---
|
||||
|
||||
## 示例片段
|
||||
|
||||
> **不好的写法**:
|
||||
> "我使用了三层架构,Controller 负责接收请求,Service 负责业务逻辑,Repository 负责数据访问..."
|
||||
>
|
||||
> **好的写法**:
|
||||
> "在实现歌单复制功能时,我最初把所有逻辑都写在 Controller 里,导致代码又长又难测试。后来我把业务逻辑抽到 Service 层,不仅代码更清晰,还能单独写单元测试了。这让我真正理解了为什么要分层..."
|
||||
|
||||
Loading…
Reference in New Issue
Block a user