软件工程实践第一次作业

[琼港]

目录

• 1.回首过去
• 1.1当初为什么会选择软件工程这个专业？
• 1.2当初对软件工程这个专业的期待和想象是什么？
• 1.3当初希望自己是如何投入这个专业的学习的？
• 2.立足当下
• 3.展望未来
• 3.1阅读《构建之法》
• 3.2未来的职业规划
• 3.3 对于软件工程实践课程，你有什么理解和期望？
• 4.思维导图和学习路线
• 4.1思维导图
• 4.2学习路线

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	软件工程实践第一次作业
这个作业的目标	绘制学习路线、制作思维导图、制定学习计划、规划未来
其他参考文献	《构建之法》--邹欣

1.回首过去

1.1当初为什么会选择软件工程这个专业？

高中时尝试用过RPGMaker做过简单的小游戏，但是被繁琐的事件处理劝退了，看着屏幕里的角色，幻想着有一天我也可以做出这样的游戏。后来深入了解这个专业，主要时游戏方面的内容，学习的是Unity，当自己想法和创意可以亲手实现时，我发现我真正热爱这个行业。从剧本，策划，程序到成品，再到被大家看见并支持，有那么一个瞬间让回忆在此刻充满温馨，让我感觉特别安心。

1.2当初对软件工程这个专业的期待和想象是什么？

当初会想到能自己亲手做出有用的软件，或者自己写的代码切实的解决了某些问题就已经很开心了。 学习的过程是交流和沟通的过程。 “做项目”感觉是 “一群人围着电脑讨论” 的热闹场景：比如小组合作做一个小游戏，有人负责画角色动画，有人写游戏逻辑，我负责做 “关卡跳转” 的功能；遇到卡壳时，大家凑在一起查资料、试代码，不是一个人闷头死磕，而是像一起闯关。这种实践里学知识的模式，比单纯听课有意思多了，也是我当初特别期待的学习状态。

1.3当初希望自己是如何投入这个专业的学习的？

其实我是大二才开始学习Unity的，说起来有点晚了。跟着西二在线的考核开始学习Unity大概从零开始学到现在有差不多一年了，通过参加大大小小的比赛不断积累经验，其实对我来说比起学习更重要的交流，大概是因为认识了同样作为游戏开发的伙伴。但有时也会问自己，到底适不适合做游戏，比起这样没有实际意义的思考不如做一些能拿得出手的东西来。做一款好玩的游戏，为此我正在写剧本ing

2.立足当下

个人简历
学号	102300314
姓名	黄逸涵
职位	福州大学VR畅游协会会长
	福州大学学生潮韵文学社编辑
成果获奖经历	2024年二十四届数学竞赛非数学专业二等奖
	2024-2025学习进步奖
	西二在线2025年Unity方向成员
	2024吉比特GameJam最佳社团创新奖
编程语言	C/C++，C#/Java ，Lua ，Python ，MYSQL ，JavaScript
开发工具	Unity ，Visual Studio ， IDEA ，Git , MATLAB
项目经历	2024吉比特高校GameJam《好想玩雪》中担任策划和主程
	萌芽GameJam《回到开始的一步》担任策划和主程
	开拓芯大学生游戏创作大赛《底片时空》担任策划和主程
	基于 Java Swing/JavaFX (前端)、Spring Boot + MyBatis-Plus (后端)、MySQL (数据库) 实现的学生信息管理系统担任后端
	本次软工实践大作业担任Unity主程序

3.展望未来

3.1阅读《构建之法》

1. 水平近似的两个人在进行结对编程时，是否会由于能力的限制导致代码质量无法提高？
   水平相近的两个人结对编程，并不会因为“能力天花板”而卡住代码质量，反而可能通过互补和持续反馈，实现“1+1>2”的效果。但是前提是
   • 两人都必须“愿意开口”，不能把结对变成“静默各打各的”；
   • 任务粒度要合适，太简单会沦为“一个人写、一个人看戏”；
   • 节奏要交替，让键盘在两人间流动，避免疲劳和思维锁定。
2. 写了再改Code-and-Fix模式真的很差吗?
   “写了再改”并不是一种“很差”的方法，而是一种非常原始、成本极高、可控性最差的开发方式。它最大的问题在于把发现和修复缺陷的时机推到了最晚，导致返工成本指数级增长。如果允许用 Code-and-Fix，本质上就是默许你用“挂科风险”去买“省事”——只要你能承受后期调试、需求变更、评分下调的代价，它就能用；否则就别把它当成正规流程。
3. 关于团队中的角色转换和转会，究竟有没有这方面的需要呢？我们团队进行了角色的转换，但大家都需要花费很长的时间进行新知识的学习，是不是降低了效率呢？
   “角色转换”不是可有可无的仪式，而是必须做的‘疫苗’；看起来短期效率下降，实则是把‘关键人员单点故障’这颗雷提前排掉。 你们现在“学新东西慢”不是转换本身错了，而是缺少《构建之法》里强调的那套“最小可迁移知识 + 阶梯式交接”的方法。只要把交接颗粒度从“整岗换人”改成“能力切片逐步渗透”，就能把学习效率压到最低，同时保留角色互换带来的长期红利。
4. 在MVP方法中，如何保证雏形产品的不完备性不影响用户反馈？
   MVP 的不完备不是“牺牲质量”，而是把不确定性拆成可验证的假设；只要让用户提前知道「测什么、为何测、测完能得到什么」，就能把“不完整”转化为有效反馈，而不是无效抱怨。
5. 虽然敏捷流程非常的迅速高效，但这是否是对团队人员的一种消耗？
   “敏捷＝短周期交付＋可持续节奏＋团队自决；
   任何一项缺失，剩下的就是加班敏捷、拍脑袋敏捷、PPT 敏捷。”
   敏捷流程允许快，但强制可持续；
   所有“快”都必须过速率数据、幸福度投票、技术债红线三道闸门。
   只要这三闸在，敏捷就是“长跑节奏器”；拆掉了，它就变成“冲刺绞肉机”。
   所以——不是敏捷消耗人，是“假敏捷”在消耗人。
6. 软件开发过程中是否有必要保证代码具有100%的正确性，如果有必要又应该如何实现呢?
   100 % 正确性不是神话，而是“钱 + 时间 + 需求冻结”堆出来的机械证明工程；
   日常业务软件追求 95 % 已经足够好，把剩余 5 % 留给监控、灰度、回滚反而更划算。

   3.2未来的职业规划

•  学习插件、巩固常用插件使用技巧(Dotween，Nodecanvas，UniTask等)
•  学习各种架构，如ECS
•  学习语言Lua、python
•  学习图形学
•  学习常用算法，掌握必要算法(A* 等)

  3.3 对于软件工程实践课程，你有什么理解和期望？

1. 理解：软件工程实践课是能够依照企业开发流程完成一个完整项目的实践课、并且以此熟悉多人开发的过程和要求、培养项目的跟进和掌控能力。
2. 期望：期望如理解，希望能够在实践课中学到完整项目的开发精髓，包括重要的系统、必要的平台等，并构建起一套完整的开发体系，以适应全流程的开发，并以制作人为目标，希望获得项目的领导经验。而对于个人技术的补充，则希望用到一套比较基础的战斗系统和完备的、可移植的UI（用户UI、状态栏、背包等）

   4.思维导图和学习路线

   4.1思维导图

4.2学习路线

​