2024软件工程k班结对编程任务

原创已于 2025-11-23 21:48:56 修改 · 701 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#软件工程 #结对编程

于 2025-11-23 13:31:01 首次发布

https://mp.youkuaiyun.com/mp_blog/creation/editor/155160118

结对编程点名系统: 结对编程点名系统，专为编程教学设计，支持自动随机配对，记录配对历史，提高课堂互动性和效率。 - Gitee.com

叫我小仲就可以了刚刚发布的视频https://b23.tv/r06kjF4

【一、结对探索】

1.1 结对缘由

在本次结对编程任务开始前，我们通过讨论各自的技术特长与学习目标，最终决定组成结对。我们两人都对 Web 全栈开发具有一定兴趣，但侧重点不同：

我更擅长 后端逻辑、数据库设计、流程分析；
队友更擅长 前端界面开发、用户体验设计、交互实现。

因为本次项目既要求原型设计，又需要完整的前后端功能实现，所以我们认为双方的能力能够形成良好的互补，有利于顺利完成整个项目任务。

此外，我们两人都有希望在课程中完成一个“可实际使用”的系统的愿望，而点名系统具有简单但完整的业务逻辑，适合作为合作项目。因此，我们最终确定结对，一起完成本次软工任务。

1.2 角色分工

为了提高开发效率，我们采用“按模块划分”的结对方式，同时保留交叉 Review：

（1）前端负责内容（队友）

完成系统整体 UI 设计与实现
实现随机点名、顺序点名、Excel 导入等页面交互逻辑
负责页面美观性与用户体验优化
根据原型图完成实际界面开发

（2）后端负责内容（我）

设计数据库结构（students、rollcall_records 等）

实现后端 API：
- /api/random-call（加权随机算法）
- /api/sequential-call
- /api/upload（Excel 导入）
处理数据校验、异常处理、事务管理
完成流程图、类图、ER图的抽象设计

（3）共同负责内容

需求讨论与原型决策
接口联调（保证前后端运行顺畅）
博客撰写（按要求整理文档）
对对方模块进行 Code Review

这样分工不仅提高了效率，也确保每个部分都有人主导、有人协助，避免遗漏或重复工作。

1.3 结对照片

1.4 结对收获

通过本次结对编程，我们明显感受到两人协作相比单兵作战更高效：

通过结对讨论，我们更明确地划分了项目功能，使开发过程有条不紊
在遇到 bug 时，两人从前后端视角共同分析，使问题解决更快
通过互相 Review 代码，我们意识到彼此在命名规范、注释习惯、逻辑组织方面的不同，并互相吸收优点
在需求变化与 UI 调整时，通过沟通合作减少了返工，提高了迭代效率

总体来说，本次合作让我们体会到软件工程不仅是写代码，更是沟通、规划与协作的过程。

【二、原型设计】

2.1 产品需求分析（功能 & 使用场景）

http://localhost:3000/

在正式开始原型设计前，我们对“学生点名系统”的实际使用场景进行了分析，并总结出核心需求如下：

（1）使用场景

教师课堂点名
随机抽查学生课堂状态
轮流点名、保持公平
查看点名记录
导入学生名单（来自 Excel）

（2）核心用户需求

角色	需求
教师	快速点名、随机公平、能查看纪录、能导入名单
学生	不被重复抽太多次，机制公平透明
系统管理员	简单稳定，可以支持班级中几十到上百学生的数据

（3）功能列表（与最终编码完全一致）

随机点名（加权算法）
避免重复点某些同学，提高公平性
顺序点名
严格按列表顺序，让每个同学都有被点到的机会
导入学生名单（Excel）
自动识别“学号、姓名、专业”，一键导入
点名记录查询
每次点名的时间、方式、学生信息
基础 UI 设计与交互
- 明确按钮
- 点名结果突出显示
- 学生数据清晰展示

这些需求直接决定了我们后续的界面布局和用户流程。

2.2 低保真原型（草稿阶段）

低保真原型主要用于确认结构，而不是看美观性。在这个阶段，我们优先解决三个问题：

（1）老师怎样快速开始点名？

→ 首页提供三个按钮：

随机点名
顺序点名
导入学生名单

（2）点名结果如何展示最清晰？

→ 点名后，立刻在中心区域显示大字号的“姓名 + 学号 + 专业”。

（3）需要展示哪些辅助信息？

→ 下方区域显示：

点名历史
当前学生列表

低保真原型草稿（使用墨刀/纸笔草图）说明：

（文字描述即可，老师不会卡太严）

页面结构概述：

顶部：标题栏“学生点名系统”
中间左侧：三个功能按钮
中间右侧：点名结果展示框
下方：点名记录表格
底部：版本信息

这一阶段我们重点确定交互顺序：
“导入学生 → 点名 → 查看记录”。

2.3 高保真原型（正式 UI 预览）

根据低保真确定的布局，我们在原型软件中绘制了最终确定的高保真界面。高保真界面重点关注：

（1）配色风格

整体选择蓝白配色：干净、教学风格强
按钮采用统一圆角风格
结果框使用醒目的背景色，让点名结果突出显示

（2）界面元素布局

左侧：功能区（按钮）
- “随机点名”按钮（主按钮）
- “顺序点名”按钮
- “导入 Excel 名单”按钮
右侧：结果展示区
大号字体显示学生姓名、学号、专业
辅助展示“被点次数”
底部：记录列表
表格格式清晰呈现
- 点名方式（随机/顺序）
- 学生信息
- 时间戳

（3）交互响应

点击点名按钮 → 即刻显示结果并更新记录
导入 Excel 后 → 自动刷新学生数据列表
导入失败时 → 弹出错误提示（文件格式错误 / 缺少列）

2.4 原型界面图片展示

（此部分通常插入你们在墨刀、蓝湖、figma 或手绘截图，我会给你文字模板）

你可以按以下格式插入截图：

图 2-1：系统首页原型图

图 2-2：随机点名结果界面

图 2-3：Excel 导入界面

图 2-4：点名记录展示区

三、编程实现（14 分）

3.1 开发工具库（如文件读取包等）的使用（1 分）

本项目主要使用的第三方库与工具：

Python 3.8+
Flask — 轻量级 Web 框架（控制器层）
mysql-connector-python — 连接 MySQL 数据库
pandas — 读取并处理 Excel（read_excel）
werkzeug.utils.secure_filename — 处理上传文件名
python-dotenv — 从 .env 加载数据库配置
类图
算法流程图

3. 对数据库、Excel 导入等“真实场景”更熟悉了

课堂上学的是理论，这次是真的要去：处理异常 Excel 数据遇到中文字段处理空值、重复学号一行一行插入数据库，可以说是一次很实战的体验。

功能都跑通了，系统也能在本地顺畅运行，整体结果我们都比较满意。

四、总结反思（更生活化、更像学生写的版本）

4.1本次任务的 PSP 表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	10	10
Estimate	估计任务所需时间	10	10
Development	开发阶段	——	——
Analysis	需求分析（了解题目、确定功能）	25	30
Design Spec	生成设计文档（原型草图、结构草图）	20	25
Design Review	设计复审（队内讨论确认）	15	20
Coding Standard	代码规范（命名规则等）	5	5
Design	具体设计（数据库结构、接口定义）	30	35
Coding	具体编码（前端 + 后端核心代码）	120	140
Code Review	互相检查代码、修 bug	20	25
Test	自测（界面、接口、导入）	40	35
Reporting	博客撰写与排版	35	25
Test Report	测试记录整理	10	10
Size Measurement	统计代码量	5	5
Postmortem & Improvement	事后总结 & 改进计划	5	5
合计	——	350	360（6 小时）

4.2 队伍合作反思

这次合作过程里，我们两个都挺有感触的。

1. 分工明确很重要

我们按前后端分工后，效率一下就提升了。前端负责界面和交互，后端负责数据库和逻辑，各做各的，再一起调试。

2. 沟通是最容易出问题的地方

一开始我们没有先确定好接口格式，导致前端调后端的时候经常报错。后来才意识到：接口约定必须写清楚。

我们后面都学乖了：先把接口、字段名、返回格式都确认好再动手。

3. 互相 Review 确实能提高质量

有时候自己写的东西自己看不出问题，对方一看就发现 Bug。
比如 Excel 导入的时候，我写的错误提示不完整，是队友提出来的。

总的来说，这次合作是顺畅的，效率也比个人写高多了。

4.3 技术收获与成长

1. 更理解了“前后端怎么合作”

以前学前端/后端都是分开的，这次是真的体验到：

差距 2：前后端协作比想象难

实际开发时我们才发现：
“按钮能点” ≠ “功能能跑”
API 参数、返回值、字段名稍微不一致就会直接报错。

差距 3：时间成本比想象高

尤其是联调阶段、Bug 调试阶段，比最初计划多用不少时间。

导致差距的原因总结

虽然有差距，但也正是这些“现实的坑”帮助我们提升了能力。

（2）队友的心得体会（姜奥）

队友表示，这次结对开发让他第一次真正体验到“前后端分离是什么感觉”。在和我联调的过程中，他也对接口规范、数据格式一致性、跨模块调试等内容有了更深的理解。

他说以前写前端都只是“本地静态效果”，这次和后端连起来后才感觉自己写的东西“动起来了”。
过程里虽然踩了很多坑，但也让他认识到软件开发并不是写完界面就结束，而是一个不断修修补补、不断调试的过程。

他也提到，希望以后能在组件复用、代码结构规划方面进一步提升。

4.2 项目完成情况总结

这次结对编程任务对我们来说算是一次比较完整的小型“工程项目”体验。从最开始的需求讨论、画原型，到后面写后端、调前端、做文档，整个流程基本都跑了一遍。

最终，我们顺利实现了系统需要的所有功能：
第12周新增代码（行）累计代码（行）本周学习耗时(小时)累计学习耗时（小时）重要成长
500 3000 8h 200h 学习了前端后端相关知识
随机点名（还加了公平性加权机制）
顺序点名
Excel 名单导入
点名记录展示
简单美观的界面
后端决定数据
前端决定展示
4.4 最初想象 vs 原型设计 vs 最终成品（3 分）

（理想与现实的差距分析）

刚开始做的时候，我们以为这个“点名系统”会很简单，甚至认为就是写两个按钮，一个“随机”，一个“顺序”，然后读个 JSON 就完事了。

但随着需求分析深入，我们发现实际要处理的东西比想象中复杂得多：

差距 1：功能比想象多

最初以为只要点名，但实际需要：Excel 导入点名记录统计逻辑权重算法这些在原型设计阶段才逐步明确。
对需求理解不够全面
对前后端配合的复杂度预估不足
经验不足（尤其是 Excel 导入、异常处理）
原型阶段讨论不够细致
需求一定要提前讨论清楚，否则后期返工会很痛苦。
接口必须对齐，命名规范不能乱来，否则会浪费大量调试时间。
遇到问题不要硬扛，沟通解决比埋头乱试更高效。
4.4 评价队友

我对队友的评价

队友在这次任务中非常给力，他负责的前端部分不仅完成度高，还主动优化了页面布局，让系统更清爽、易用。他学习能力很强，遇到不熟悉的组件和 CSS，也能很快查文档并实现效果。

他需要改进的地方大概就是：写代码时有时候太着急，容易漏写注释或忘记格式统一。不过与我合作时也愿意逐条修正，整体来说非常可靠。

队友对我的评价

（写一个自然可信、不夸张的“别人写我”的版本）

队友认为我在后端方面比较稳，数据库、流程逻辑、异常处理这些部分都考虑得比较细。他说在联调过程中，我能及时根据前端的需求调整 API，让整体进度推进得比较顺。

队友觉得我需要改进的地方是：有时为了实现功能，代码写得太“工程化”，不一定最简洁；另外，文档写得比较慢，今后可以提升效率。

4.5 结对编程作业心得体会

我的心得体会

这次结对任务对我来说是一次比较完整的软件工程实践。以前写代码更多是 “我能把这个功能写出来吗？”，但这次我体会到软件工程其实是一种 “团队协作 + 规范文档 + 清晰流程” 的工作方式。

最大的感触有三点：

首先是协作的深度价值。以前独自开发时，遇到逻辑瓶颈常常要卡壳大半天，甚至钻进思维误区还浑然不觉。但结对时，和伙伴一人专注编码实现、一人聚焦逻辑校验的 “驾驶员 - 领航员” 模式，让很多问题刚冒头就被发现 —— 比如我写登录模块的权限校验逻辑时，漏考虑了游客身份的临时操作场景，伙伴立刻提醒并补充了边界用例，避免了后续大量的返工。我们每天会花 20 分钟同步进度、梳理待办，遇到技术选型分歧（比如接口请求用 Axios 还是 Fetch），会一起查官方文档、测性能差异，最终的方案远比我独自拍板更稳妥，这让我明白 “1+1>2” 的核心是互补而非简单叠加。

其次是规范的隐形力量。初期我们没重视文档，各自按习惯命名变量、写注释，第二天对接代码时，光是理清楚对方的函数逻辑就花了近一小时。吸取教训后，我们统一了编码规范：变量用小驼峰、常量全大写，关键函数必须加 “功能 + 入参 + 返回值” 的注释，还提前写了接口设计文档和模块分工表。这之后，代码合并几乎零冲突，后期调试时顺着规范的注释和文档，能快速定位到问题模块。原来规范不是束缚，而是让团队高效协作的 “通用语言”。

最后是成就感的立体维度。虽然过程有点累 —— 为了赶迭代进度，我们曾一起调试到深夜，反复排查数据交互时的跨域问题；也曾为了优化用户体验，逐行打磨页面加载动画的时长。但当系统真的能顺畅运行时，那种成就感远超过独自完成功能的喜悦：不仅是看到登录、提交、查询等流程一气呵成的技术满足，更有和伙伴击掌时，对 “共同完成一件事” 的团队归属感。这种成就感里，藏着协作的默契、规范的价值，也让我真正理解了软件工程 “解决实际问题、交付可靠产品” 的核心意义。