[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13465
我在这个课程的目标是	学习软件工程的基本方法，提高工程化能力
这个作业在哪个具体方面帮助我实现目标	总结反思，为以后的工程化开发积累经验教训

对曾经问题的解答

提问博客的链接

问题1

问题描述：

若结对双方技术栈差异显著（如一人仅熟悉前端，另一人专精后端），是否会导致代码理解不同步，从而削弱协作效率？此时是否必须要求双方均为全栈开发者？若无法满足，是否存在其他实践方式来维持结对编程的核心价值？

理论上来讲，最理想的情况当然是双方均能够进行全栈开发，这显然能够使开发效率更高。而在我的结对编程过程中，我和搭档的编程模式更像是一个相互学习的过程，由更擅长处理当前任务的一方进行讲解，另一方则以提问、记录、验证的方式参与，这样的模式有助于快速缩小技术的认知差距，最终也能得到一个较高的开发效率。

问题2

问题描述：

代码作者编写测试时，其固有思维可能遮蔽潜在漏洞（人总会有思维定势）。这是否意味着“最了解代码的人”反而容易成为“最盲目的测试者”？是否有必要引入交叉评审或测试用例设计规范来规避此类风险？

实际开发过程中，我作为后端工程师在测试时确实会存在这样的问题，即总是倾向于按照自己预定的逻辑编写测试用例，验证预期行为。这种自我确认的倾向确实会忽略一些潜在的问题，有时是开发层面的问题，有时则是前后端开发者对接口文档的理解不同而导致的问题。

在测试阶段，我修复了很多大大小小的问题，这些问题大部分都是我和前端的同学共同测试时发现的，这说明引入交叉评审确实能够跳出原开发者的思维边界，发现更多潜在的问题。

然而，在这个过程中也存在沟通效率方面的一些问题，如果要改进的话，可以从沟通工具和时间协调等方面入手，进一步提升测试环节的效率。

问题3

我的问题：

若团队能力不足（如临时组队的大学生），如何在不具备“自组织、跨职能”属性的前提下适配Scrum？是否应适当简化流程以降低实践门槛？

就大作业的小组而言，我们确实存在团队能力有限、缺乏自组织和跨职能能力的的情况。实际开发过程中我们确实一定程度简化了开发流程，只保留了Scrum的一些核心思想，包括小步快跑，持续交付可用功能；尽可能保持团队沟通透明；明确各自的职责，对自己的工作成果负责等。这让我们能够在有限的时间里最大化完成任务，并且避免了流程僵化和形式主义导致的效率低下问题。因此，在团队能力不足的情况下，适当地简化开发流程是合理且有必要的。

问题4

我的问题：

“不犯大错”虽能规避风险，但可能导致团队回避创新尝试。例如，过度保守是否会让项目错失某些潜力很大的技术风口？作为资源有限的学生团队，是否应在“稳健”与“激进”间寻找平衡点？

就实际情况而言，我们的小组作业是经历过一个从“激进”到“稳健”的转变的。

起初我们准备做一个卡牌类游戏，小组成员集体对卡牌的玩法和机制进行了体验和评估，没有什么大的问题。但到了实践阶段，我们逐渐发现自己的能力不足以在规定的时间内完成这项任务。问题有二，一是美工的工作量过大，二是组里没人拥有Unity开发经验，学习时间成本过高。

于是经过慎重考虑，我们最终选择了一个采用传统Web前后端技术栈的项目，这使得我们能够快速上手进行开发并在短时间内拿出一个完成度比较高的版本，在开发的后期也有较多的时间进行优化和完善。

所以，我认为对于学生团队来说，完成任务的优先级一定是大于创新的，一定要客观评估自身的能力，先保证完成度再考虑探索和创新。

问题5

我的问题：

若测试与开发的界限过于模糊（如测试人员参与需求设计），是否可能导致职责混乱？反之，若界限过严，是否会降低测试效能？怎样才能够实现两者之间的动态平衡？

由于团队人数较少以及任务分配不均，我们的大作业开发过程一直存在劳动力不足的问题，开发人员不得不参与到测试以及需求设计的环节中，一个人身兼数职是普遍情况。

但从结果来看，这样反而提升了团队沟通的效率与质量，因为身兼数职会让我们不得不从其他职位的开发者的角度出发去思考问题，这样就能提前避免一些不必要的麻烦，避免了你做你的我做我的最后两边对不上的问题。

所以我认为不论职责边界是否模糊，开发者都要尽可能从团队中其他成员的角度出发思考问题，这样一定能提升团队协作的质量。

请问你们在项目的需求/设计/实现/测试/发布/维护阶段中都学到了什么“知识点”

需求阶段

在确定需求时，有的同学可能会为了在竞争者中脱颖而出/拿到更高的分数而做一些激进的决定，却忽略了自身能力不足而导致的局限性。我认为在这种课程大作业的场景下，完成度的优先级一定是大于创新思想的，一定要保证先做完再去考虑创新点和加分项。

所以现在看来，我们小组更换选题的决定是相当明智的，这才是刚好适合我们平均开发能力的选题。尽管最终还是有一些不尽如人意的小问题，但这样也远远好过加班加点都无法完成的结局。

设计阶段

设计阶段不能只有需求而没有具体的分工，因为有的需求的实现难度在设计阶段是比较模糊的，只有快速进行明确的分工并马上进行实践才能发现具体的问题。尽可能早地发现实际问题，才能有足够的时间进行调整，防止后期问题集中暴露而没有足够的时间进行解决的情况。

就我们的开发过程来看，这样的问题是一直存在的，尤其是到了beta阶段，我们一直在设计层面调整前期的决定，部分调整甚至会导致底层的重构，浪费了很多时间。

实践阶段

从后端开发的角度来看，进行开发时一定不能过度信任接口文档（很可能前端还没有彻底明确自己的需求，这样的接口文档更像是一个demo的性质），一定要与前端进行沟通，确认最终的需求后再进行开发。

如果不进行详细的确认就进行盲目开发的话，在后期前后端联调时就会出现各种问题，甚至出现请求和接收格式都对不上的情况。尽早进行前期的沟通与协调一定能最大程度地避免这样的问题，减少后期的麻烦。

测试阶段

我们没有专门的测试人员，都是直接由开发者进行协作测试。因为除了前端和后端开发人员，其他人对于代码层面几乎没有什么接触，他们无法洞察底层逻辑层面的漏洞，只能进行比较浅层次的测试。

这个阶段我与前端同学合作发现了很多问题，大部分都是前期沟通不到位以及部分前端开发同学进度落后导致的。在测试时，我们主要通过微信来进行沟通，这种形式的沟通效率比较低下，也在一定程度上拖累了测试的进度，我认为这是测试阶段最需要改进的地方。

发布阶段

进行了充足的测试之后，我们会下意识地认为程序已经不存在问题，于是直接进行发布。然而测试阶段只是解决了一些功能层面的问题，程序发布后还可能面临一些别的我们没有考虑到的问题，比如服务器自动重启后相应的服务不能自动运行这样的情况。

要解决这种问题，就需要我们跳出代码层面的思想，充分理解程序发布后的需要达到稳定运行的各种条件，提前考虑到可能出现意外的各种情况，并做出相应的应对措施。

维护阶段

程序发布后，由于我们没有在发布阶段做出充足的准备，我们遇到了服务器崩溃重启后程序运行所需的服务中断的问题，这是我们在开发阶段没有思考过的角度。

我们无法解决廉价服务器运行不稳定的问题，也没有足够的经费租赁更稳定的服务器，于是我自己手动编写了一个在服务器启动阶段自动执行的脚本，这个脚本中包含了启动所有必要服务的指令，最终解决了这个问题。

结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得

这次软工课程的学习，总体来说算是中规中矩吧 ，并没有达到我理想中的程度，但考虑到我起初只是不想做嵌入式才退掉wj老师的课转投到lj老师这边，所以这样的结果也可以接受。

首先是结对编程，这个环节我是幸运的，在群里抽盲盒找到了dx同学做我的队友。我们虽然都没有接触过AS语言，但二人都能够拿出积极的态度进行学习和交流，遇到问题能够一起解决，当天没有完成的任务能够积极相约在第二天解决，绝不拖泥带水。我们花了若干个上午和晚上完成了所有的结对作业，期间我们有时共同解决一个问题，有时分别写一套代码，最终进行比较，用性能更好的版本进行提交。尽管每次连续几小时的编程有些累人，但很高兴我们最终能够按照自己的预期完成作业。

我的团队项目整体来说比较坎坷。我自己在学期刚开始就预判这次软工团队作业会用到一些我们没有学习过的技术栈，于是花了大概半个多月时间系统地学习了spring boot框架，保证自己能在后端层面贡献足够的力量。后来我确实成为了团队中的后端开发人员，但实际开发过程却充满了各种各样的问题。

首先是需求阶段，我们由于好高骛远选择了超出自身能力的选题，不出意外的话我们大概率无法按期交付完整的程序。幸运的是zx同学在事情发展到无法回头以前站了出来，仔细分析了当前选题的不现实之处，并发出了更换选题的提议。最后在大部分成员的赞成下，团队选择了更合适的选题，避免了无法完成的局面。

在开发阶段，我们团队同样存在一些问题。首先是沟通层面，每次团队集体会议总是有人要请假，我的印象里除了第一次会议以外，没有一次是全体成员都能到场的；除了集体沟通的缺席以外，有的成员在线上沟通时也喜欢玩失踪，甚至出现消息超过24小时都不回复的情况。另外，团队也存在任务分配不均以及开发进度不协调的问题。我所开发的后端部分基本上在四月底都已经完成，在此之后我的工作一直都是不断调整代码以适应前端变化的需求。而前端方面的进度就相对落后很多，前期的接口文档甚至带有一些示例的性质，直到前端彻底开工以后才逐渐明确最终的需求。甚至登陆接口一直等到五月底六月初才最终确定，在之前已经进行过若干次调整，而这最后一次调整甚至导致了数据库四五个数据实体的重构以及后端代码十五个类的修改，浪费了很多本不必要浪费的时间。

总体而言，我最深刻的感受就是沟通在团队开发中的重要性。不管在前期还是后期，充分且高质量的沟通都能够帮我们避免很多不必要的问题，这样才有可能充分的发挥出团队的潜力。

但瑕不掩瑜，虽然存在这样那样的问题，但我们最终还是完成了所有的开发工作，交付了一个完成度比较高的产品。我自己也在开发过程中进行了充足的实践，巩固了我后端方面的技能，达到了自己的预期。

最后，我要重点感谢zx和zyj同学，他们二人在前端开发过程中贡献了很多力量，甚至为了赶进度进行了通宵的开发。在后期收尾阶段也是zx同学不厌其烦地频繁与我沟通，我们合力解决了前期遗留的众多问题，最终才能按期进行交付。