现代软件工程 - 2025年秋 - 期中学生总结和反馈
在任何教学和培训中，我们都希望建立一个 NCL的环境，师生双方都希望得到尽量及时、直接、有针对性的反馈，并根据反馈进行进一步讨论和改进，而不是：
- 教练：你一开始练，我就看你举重姿势不对，当时说了一下但是你好像不听，那我也不说了，好，现在你膝盖废了...
- 学员：我早就不爽学院和老师的某些做法了，现在四年过去了我总算混毕业了，可以吐槽一下了。
之前的项目介绍和风险： 影评家（AI）对项目的风险分析
同学们的总结博客的排名：
| 团队名 | 博客链接 |
| MyMind |
软件工程质量建议：https://www.cnblogs.com/xinz/p/19290806 |
| 感情日记 |
软件工程质量建议：https://www.cnblogs.com/xinz/p/19287702 |
| FocusPet |
FocusPet Alpha Postmortem - Yu Zhao 软件工程质量建议： https://www.cnblogs.com/xinz/p/19287716 |
| Quant量化 |
NeuroQuant Alpha阶段团队总结博客-CSDN博客 软件工程质量建议： https://www.cnblogs.com/xinz/p/19287729 |
| 基因算法 |
软件工程质量建议：https://www.cnblogs.com/xinz/p/19287794 |
| PQ.next | PQ.v.Next Alpha Postmortem - Bingzheng - 博客园 |
| 阅读插件 |
https://blog.csdn.net/weixin_66127536/article/details/155239736 软件工程质量建议：https://www.cnblogs.com/xinz/p/19290498 |
| 图库 |
https://blog.csdn.net/liwy2019/article/details/155195489 软件工程质量建议：https://www.cnblogs.com/xinz/p/19290548 |
| AI租房 |
“租易 - 快捷租房管理小程序” Alpha 阶段团队贡献分与 Postmortem 会议总结文档 - zq951 - 博客园 软件工程质量建议：https://www.cnblogs.com/xinz/p/19287660 |
| NewsMind 新闻推荐 |
软件工程质量建议：https://www.cnblogs.com/xinz/p/19290563 |
| 三角洲 | https://www.xiaohongshu.com/explore/6926e8e5000000001e00fb9c?xsec_token=ABHaEsAxdxZ3D43UCPW7JcrEPyu5BR4eA358yHkr_98Qs=&xsec_source=pc_user |
| 汪洁步道 | https://blog.csdn.net/bboy_lemon/article/details/155228601 |
反馈的总结:
整理后的原始反馈，以下是每一类目前最需要改进的 2-3 个核心问题总结 (AI 总结，个人修订）：
一、 对个人 (Personal)
目前最显著的问题是“假借 AI 之手的虚假繁荣”，许多学生反思自己过度依赖 AI 生成代码而缺乏深入理解，导致后期维护困难且个人能力提升有限。其次是工程习惯的缺失与拖延，普遍存在将 WBS、博客复盘等文档工作堆积到里程碑截止前突击完成的现象，而非将其融入日常开发流。此外，学生急需建立MVP（最小可行性产品）思维，以停止过度追求完美导致的无效开发，学会平衡功能完整性与交付时间。
二、 对团队 (Team)
团队协作最大的痛点在于 “最后一公里”的恐慌，普遍低估了跨平台打包、部署和集成测试的难度，导致风险在临近交付时集中爆发。内部沟通存在严重的“信息孤岛”与单点依赖，如默认由一人承担后端或 DevOps 工作，缺乏全员的代码审查与架构共识。此外，团队急需建立明确的DoD（完成定义）与验收标准，以杜绝含糊的需求变更和“写完代码就算完成”的错误认知。
三、 对助教 (TA)
学生最迫切需要的是信息的结构化与集中化，希望 TA 能维护一份持续更新的 FAQ 或要求总览，而非将重要指令散落在零碎的聊天记录中。反馈机制需要从“被动答疑” 转向 “主动的实战演示”，例如增加 Live Code Review 环节，直接演示何为“代码坏味道”而非仅做文档纠错。同时，评分标准需要更加透明与前置，最好在迭代前提供具体的评分维度示例，避免学生因误解规则而做无用功。
四、 对老师 (Teacher)
课程内容上，学生强烈呼吁减少纯理论推导，大幅增加现场工具链（CI/CD、看板）的“从零演示”，让学生能看着老师操作一遍从而快速上手。案例教学方面，比起标准答案，大家更渴望听到真实的 “失败案例”与血泪教训（如烂尾、解散的项目），以增强对真实工程复杂度的认知。此外，希望老师能加强阶段性的复盘与目标对齐，在每个里程碑前结合当前项目实际回顾重点，指导学生如何做技术取舍。
五、 对学院 (College)
学院层面最核心的改进需求是打破课程间的壁垒，实现 “一套项目、多课复用”的联动机制（如数据库、OS、AI 课共用一个项目），避免知识割裂。学生普遍反感“为了写报告而做的一次性玩具实验”，呼吁推广本课程这种长期演进的真实项目制，让项目能贯穿整个学期甚至跨学期。此外，希望学院能提供更实质的基础设施支持（如服务器资源、经费或企业实习对接），让工程实践具备真实的物理环境支持。
详细的分类总结（大部分是学生的原文）：
对个人、对团队、对助教、对老师、对学院五个类别分类（注：原“对老师/学院”在部分语境下重合，此处根据内容指向做了细分）。所有内容尽量保持原文的风味。
一、对个人（Self）
（关于自我反思、改进承诺与学习计划）
-
如果重来一遍，我希望我自己会…
-
停止做： 停止把 Sprint 文档和博客集中堆到 ddl 前一两天才补。
-
： 我会把博客当成“开发日志”，每次完成一个清晰的小里程碑就立刻记 3–5 行：做了什么、为什么这样设计、还存在什么风险。
-
-
停止做： 停止一开始就把需求文档拖到最后完成，而是更主动地在每周固定时间整理进度与风险。
-
停止做： 停止过度追求完美，导致某些功能开发时间过长。
-
： 我希望能够更好地平衡功能完整性和开发效率，采用 MVP 思维，先实现核心功能。
-
-
做新的： 开始给自己做一个对应 WBS 的“个人学习 / 任务看板”，用一列放软件工程实践、一列放 AI 决策逻辑、一列放量化知识。
-
： 我会在每个 Sprint 开始时，从 WBS 里挑出 2–3 个“我负责的关键任务”贴到看板上，写清楚验收标准。
-
-
做新的： 我不会完全依赖 AI，而是在结对编程中自己先把电梯的后端逻辑理清楚。
-
做新的： 我希望在课程后更加具有开源精神。
-
-
关于习惯与技能提升
-
： 我希望在这门课程中，我会继续保持每次迭代都写小结的习惯，因为这让我能更快发现自己的盲点。
-
： 我希望在这门课程中，我会尝试做新的工具实验，例如引入更成熟的 CI/CD 流程。
-
： 我希望在 Beta 阶段能够更早地建立代码审查机制，避免在代码质量上走弯路。
-
： 我希望能够更主动地学习新技术，而不是等到项目需要时才去学习。
-
： 我希望能够更详细地记录技术决策过程，为后续项目提供参考。
-
： 我希望能够建立更完善的知识库，记录团队在开发过程中遇到的问题和解决方案。
-
： 我希望能够编写更多的单元测试和集成测试，提高测试覆盖率。
-
-
个人遗憾与反思
-
AI 写出来的效果也不一定那么好，如果课程重新来一遍我希望我可以上课前提前学习对应课件，补充自己的相关知识。
-
对的，结对编程我也承认存在比较大的问题，也是不懂又想快速完成，所以只能依赖 AI，结果也不尽人意，如果再来一遍，会沉下心逐步去理解。
-
当然，对这门课程中具体的软件编码工作大多依赖 vibe coding，对自身代码编程能力的提升并没有很大改善。
-
我在团队中做的贡献并没有我一开始加入团队中承诺的那么多，这是我希望改善的点。
-
当然，我在团队中很多的创意和想法都来自于 AI 辅助，作为可以创造新想法的人类的贡献寥寥无几。
-
二、对团队（Team）
（关于协作模式、开发流程、项目管理与产品方向）
-
协作与沟通
-
关于团队： 希望继续保留结对与小组合作形式。
-
： 能否在早期就安排一次“随机组队的短冲刺小任务”，让大家先体验一次小规模协作，再决定长期项目队伍。
-
-
关于团队： 希望停止“默认一人扛后端/DevOps”这种状态。
-
： 课程可以在中期专门安排一节“把项目交给别人来部署”的课堂活动，强制练习一次“让另一个人成功跑起来自己的项目”。
-
-
我希望团队交流更充分。
-
： 我希望我们团队会在每周会议中加入 5 分钟的“阻碍扫描（blocker check）”，确保每个人的困难可以被更早发现。
-
： 我希望我们团队会继续保持在代码评审时“先肯定再建议”的氛围。
-
： 我希望团队能分工更加明确，并且讨论更充分。
-
： 我希望我们结对编程的时候能把工作分好，每个人负责理解一个模块，然后把这块讲给大家听。
-
-
项目管理与流程（Stop/Start/Continue）
-
停止做： 停止“临近里程碑才疯狂赶工”的节奏。
-
： 下次我们会把“最后一公里”任务拆得更细、前移到 Sprint 1。
-
-
停止做： 停止一次性大提交、含糊的 commit message。
-
： 下次我们会坚持小步提交 + 结构化 commit message。
-
-
停止做： 停止只在本机手工点点点做回归。
-
： 下次我们会优先为关键路径补上自动化测试。
-
-
停止做： 停止忽视“最后一公里”工作（打包、签名等）。
-
停止做： 停止忽视“用户体验细节”。
-
停止做： 停止把 WBS 当成“开 Sprint 时写完然后放着不管的仪式文档”。
-
： 我们会在每次 Daily Scrum 后主动更新 WBS 中关键任务的工时和剩余工作量。
-
-
继续做： 继续把课程作业和真实项目捆在一起做。
-
： 下次我们还是会用课程要求来“倒逼”自己做出可发布的产品。
-
-
继续做： 继续在博客里写正式的工程复盘。
-
继续做： 继续保持清晰的角色分工和贡献透明。
-
继续做： 继续用 Daily Scrum + Kanban 管理进度。
-
新增做： 新增一套“个人学习 Backlog”。
-
新增做： 新增团队级的 Definition of Done（DoD），确保通过 CI 和测试才算完成。
-
-
产品与需求讨论（头脑风暴风格）
-
关于功能： 根据不同的需求给出不同的卡组。
-
对，但是： 我们先要对需求进行分类。
-
对，我们应该： 向用户询问他们的需求。
-
对，但是： 很多时候用户也不知道他们的需求是什么，尤其是新颖的 AI 产品。
-
对，那我们可以： 找同类产品进行调研。
-
对，我觉得： 讲故事的方法很重要。
-
对，我们应该： 找到我们的核心思路。
-
对，但是有时候： 好的体验很难言说，但是我可以在营销的时候用这种话术来调动用户的兴趣。
-
对，我们需要： 告诉用户他们需要什么，需要用户教育，需要 quest line 来充当长期反馈。
-
对，我们不应该： 过于发散功能。
-
对，我们可能需要： 一个设计主题，这样我们可以把我们的功能都归到这个框架下。
-
对，尝试： 不同的形态。有边界的尝试。
-
对，但是我们自己： 并不到这个合适的聚焦的点是什么，所以我们可以 build in public。
-
-
关于后续计划： 调研学术研究，看看怎么发 paper；引入成熟的研究比如 HOOK model；想象社交裂变的机制。
-
对，但是这一切都必须： 基于手机 APP，得做出来看看效果。
-
-
团队愿景
-
我们希望我们团队会赚很多钱，并继续把这个项目持续完善。
-
在团队成员的管理上，我没有很好的管理手段，导致大家的工作进度不统一，大大降低了开发工作的效率（作为反思）。
-
三、对助教（TA）
（关于答疑、评审、反馈机制与工具支持）
-
沟通与答疑
-
关于 TA： 希望继续保持高频在线答疑（微信群 / Issues）。
-
： TA 可以鼓励大家把问题尽量发到 GitHub Issues 上，而不是只在私聊里问，减少重复劳动。
-
-
： 我希望 TA 会继续在 Slack/群聊中快速回应关键技术问题。
-
： 我希望 TA 能够定期组织技术答疑会，帮助团队解决技术难题。
-
： 希望 daily scrum 能及时提交，并且助教早点提醒我们没交。
-
-
评审与反馈
-
关于 TA： 希望新增“代码走查 / Design Review”环节。
-
： 可以每个迭代由 TA 挑几个团队做一次 15 分钟的 Live Review，不是找碴，而是演示“什么是可维护的代码结构”。
-
-
： 我希望 TA 会在每次迭代前给我们明确的评分重点示例，让我们知道真正被考量的维度是什么。
-
： 希望 TA 能维护一份持续更新的 “项目 FAQ / 要求总览” 文档，把必须交付的文档列表、评分关注点集中起来。
-
： 开始不定期针对各组的 Alpha 产物给结构化反馈（亮点 2 条 + 改进建议 2 条）。
-
： 我希望 TA 能够提供更多的代码审查建议，帮助团队提高代码质量。
-
-
管理与指导
-
： 我希望 TA 能够定期检查项目进度，及时发现和提醒潜在问题。
-
： 我希望 TA 能够提供更多的项目管理和团队协作方面的指导。
-
： 我希望 TA 能够帮助团队建立更好的开发流程和规范。
-
四、对老师（Teacher/Course）
（关于课程设计、授课内容、案例教学与作业安排）
-
课程内容与授课方式
-
关于课程本身： 希望继续保留真实项目驱动。
-
： 如果能在开学第一周就给出历届优秀项目的 Demo 和“失败案例故事”，会更有助于理解“现实感”。
-
-
关于任课老师： 希望继续讲真实项目故事和“血泪教训”。
-
： 分享更多和我们项目规模类似的“校园或创业项目”的真实经历（包括解散、烂尾的）。
-
-
关于任课老师： 希望减少纯理论推导的篇幅，增加工具实践 Demo。
-
： 比如在讲燃尽图、CI/CD 时，直接现场从零演示一次“建看板 → 提 Issue → 写简单 CI 脚本”。
-
-
： 我希望课程老师会增加一些真实软件工程案例（特别是失败案例）的分析讨论。
-
： 开始安排 1–2 次中期项目分享会，请几组 Alpha 进展比较有代表性的同学展示他们的系统。
-
： 在讲授复杂主题时分步骤示范关键流程，并展示可直接参考的标准示例。
-
： 在课堂中设计更多互动活动，如团队讨论、架构设计、即兴 code review。
-
-
作业与项目要求
-
关于课程本身： 希望减少零散作业、加强与项目的绑定。
-
： 把一些小作业改成“直接写在项目仓库或团队博客里”，而不是再交一个单独的 PDF。
-
-
： 我希望课程老师会继续允许我们在方法与技术栈上保持灵活性。
-
： 希望老师能在每个重要提交前，结合项目简单回顾一次：“这次更看重什么？”。
-
： 在布置项目与作业时给出明确的验收标准，并从工程团队的角度解释这些标准的必要性。
-
： 我希望老师能够建立更完善的评分标准。
-
： 我希望老师能够根据团队的实际进展，灵活调整作业要求和截止时间。
-
-
其他建议
-
： 我希望课程老师可以建一个专门的通知群，用于发布重要消息。
-
： 我们希望本课程的老师会降低这门课程的任务量（注：与部分“希望增加挑战”的反馈对立，保留原文）。
-
： 我希望老师能够邀请行业专家进行讲座，分享真实的软件开发经验。
-
五、对学院（College）
（关于课程体系联动、资源支持与教学改革）
-
课程联动与体系
-
关于学院其他课程： 希望和这门课有更多“联动任务”。
-
： 数据库、操作系统、人工智能等课程可以允许/鼓励我们直接用本课程的项目作为实验对象，一套项目多门课复用。
-
-
关于学院其他课程： 希望停止那种“只为了写报告的玩具实验”。
-
： 如果能像这门课一样，以“长期演进的一个项目”贯穿几门课，会更有成就感。
-
-
： 我希望学院的其他课程也能加强“项目导向”的设计，让不同课程之间的知识能形成互补。
-
： 开始设计跨课程的长期联合项目，例如“软件工程 + 金融工程”共用一个基础项目。
-
： 希望其他软件工程课程能够系统讲解架构设计的核心思想，并配合大型系统的真实架构演进案例。
-
： 何绍斌希望学院其他课程也能像《现代软件工程》一样，增加作业量与博客要求，具有挑战力。
-
-
资源与支持
-
能不能让学院出钱资助？
-
向学院申请经费、服务器，目前用的就是课题组的 API。
-
可以向工程导师寻求帮助。
-
-
： 学院可以与企业合作，提供更多实习项目，让学生在真实环境中锻炼技能。
-
： 我希望其他课程能够提供更多的实验环境和开发工具。
-
： 我希望其他课程能够建立更完善的学习资源库。
-
-
教学模式改革
-
： 停止忽视跨学科的课程设计，学院可以设计更多跨学科的课程。
-
： 加入团队协作的实战训练，如接口约定、冲突处理与多人代码规范保持。
-
： 教授工程文档、技术写作、Postmortem 等职业工程师的重要能力。
-
： 我希望学院其他课程中对于学生实践性、互动性、教学性相对来说比较匮乏的情况能有所改善，向《现代软件工程》课程学习。
-
浙公网安备 33010602011771号