北航软件工程 [I.3] 个人作业：结课总结

北航软件工程 [I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习融会软件工程理论，参与真实项目的开发全流程，积累软件开发的经验
这个作业在哪个具体方面帮助我实现目标	在课程结束后经过回顾总结反思，发现问题，提炼经验

---

问题回顾 [I.1] 个人作业：阅读与提问

问题一：如何平衡单元测试与复杂逻辑？

原问题核心：教材提出单元测试应覆盖所有方法、所有参数、所有代码路径甚至私有方法，但在现实中遇到随机数、外部依赖、多线程等非确定性逻辑时，这些标准很难落地；而为了可测试性过度拆分又会导致代码破碎。如何在实际开发中平衡？

当前解答：从根源看，单元测试的真正目的是防回归，而非机械覆盖所有代码。务实做法是按函数分类：核心算法与工具函数需严格边界测试，胶水编排代码仅冒烟即可。对随机/时间依赖，将其作为参数传入使核心逻辑纯化；多线程安全无法靠单元测试证明，靠静态扫描和压测。为避免为测试而抽象导致代码膨胀，宁可直接测试实现类也别为Mock而拆分。评价指标侧重核心分支覆盖率、测试稳定性和执行耗时，而非全局行覆盖。

问题二：结对编程适用于什么场景？

原问题核心：结对编程的初衷是将复审和交流融入编程过程，但加入另一个人是否会干扰编程计划、引发冲突或忽略大局？"老带新"时角色应如何分配，资深经验是否会扼制新手的思维创新？

当前解答：结对编程的适用场景确实很窄，在课程的真实体验中，两个同学操作起来会有些别扭。它不适合日常开发中个人熟悉且机械的编码任务，那种场景下独立规划和连续心流才是最高效的，强行结对会打乱个人计划。结对编程真正有价值的地方有两个：一是处理复杂的关键模块设计或高风险重构，此时实时了解方案细节能快速过滤掉不成熟方案，避免后期返工；二是"老带新"，资深人员主导设计思路和全局把控，新手负责代码落地，这样既能保证质量，又能让新手在动手实践中理解架构脉络，但是会产生比较大的时间开销。

问题三：敏捷开发如何与测试工作相融合？

原问题核心：敏捷快速迭代对回归测试提出高要求，是否意味着自动化测试是敏捷的前提？对难以自动化的测试应如何安排？测试人员融入团队后，开发者各自测试零散模块能否完成有效的系统级测试？

当前解答：敏捷开发确实需要自动化测试来支撑快速迭代的回归验证，但自动化不必覆盖所有场景。单元测试和接口级回归应自动化并纳入CI流水线，而复杂的UI交互或硬件兼容性测试则不能强求在每个迭代中自动化，可安排为定期的探索性测试或季度级别的集成验证，用自动化辅助人工判定即可。至于"测试人员融入团队、每个人自己搞定测试"，这并不等于让开发各测各的就算完事，而是开发者负责自己的单元测试和模块内集成测试，系统级的端到端验证和测试策略仍需专职测试人员统筹，梳理场景、补充边界、推动团队整体测试能力，这样分层协作才能真正跟上迭代节奏。

问题四：敏捷开发团队要求每一个成员都各技能均衡吗？

原问题核心：教材实例中工作量偏差达1.5倍，由程序员不熟练还是开发模式导致？前后端依赖下前端前期无事可做，是否要求成员都是全栈？

当前解答：敏捷开发并不要求团队成员都是全栈多面手，那种"每个人什么都能干"的理想状态在实际项目中很少，核心是倡导T型人才——每个人有自己深耕的领域（前端/后端/系统），同时具备跨职能协作的基本意识和能力。在实际任务分配上，前端工作在前期并非无事可做，可以编写Mock数据、参与接口契约定义、提前搭建页面骨架和组件库，或者与后端人员结对梳理需求细节，而不是被动等待。

问题五：每日立会会不会演变成"罚站大会"或"吹牛大会"？

原问题核心：复杂任务中长期无进展时，成员反复汇报"昨日没进展"会否挫伤自信甚至导致瞒报？如何识别立会已变成形式主义？这是团队文化问题还是Scrum设计问题？如何调整让立会回归本质？

当前解答：每日立会确实很容易变味，但原因并非Scrum本身的设计缺陷，而是把"同步信息"和"汇报工作"混在一起产生的问题。一旦成员觉得立会是向上汇报自己有没有干活，而不是向团队求助和同步进展，那它必然走向形式主义。至于调整方法，核心是Scrum Master要仔细识别真正的问题在哪，或是想办法让成员主动提问；对于长期停滞的情况，散会后马上拉个小会定向解决，尽量不要让成员在立会场上反复暴露自己的无力感。Scrum只是工具，它无法解决人性问题，但一个好的Scrum Master可以用实际行动让立会回归协作本质。

“做中学”

1. 需求阶段：

   • 需求需要落地，可能有很多，在敏捷开发中需要先做对用户最重要的部分。
     在团队项目的前期讨论中，虽然确认了大致的软件雏形，但是并没有做进一步的细化，成员之间其实并不清楚具体包括哪些功能细节，每个成员在脑海中对软件的描绘可能差距很大。这也为后续带来了很多问题。在选题确定后，团队列出了十余项功能，但是在Alpha阶段中想做完所有的功能是很困难的。我们挑选了一些核心功能作为项目的基准，力求Alpha阶段发布时能够让用户具有完整的体验；而剩下的边缘功能则留到Beta阶段完成。

2. 设计阶段：

   • 团队需要在设计阶段做好协调，产出可持续使用、检查的说明性实体，避免对后续产生连锁影响。
     这个部分可以从接口部分来说明。设计时，团队很多成员在分配任务时将规范类、文档类的任务置于拓扑链后端。我在最开始时在文档库中编写了初期API接口规范，但是我在前后端连接时发现后端提供的接口路由地址与规范中提到的注意事项完全相反，导致一直不知道问题发生在哪。

3. 实现阶段：

   • 团队应当遵循相同的代码风格，以及提交信息、合并信息等的语言风格。
     在搭建CI/CD时，团队正式规定了详细的代码与提交规范，这既方便了日常开发中的代码一致性维护，也为后续一次合并事故提供了便捷的回溯。通过检查特定时间段内的提交信息，发现了问题。

4. 测试阶段：

   • 边界异常场景测试比正常流程测试更重要、更能发现问题，同时如果测试人员也担任开发任务的话，要脱离自身的成熟环境进行多方测试。
     在测试阶段，前后端都出现了同样的问题，就是开发时迭代完善了个人的环境，自行测试也是在完善的环境上进行，没有在隔离环境中测试。同时在Beta阶段测试时，尝试了过长文本、大内存图像等数据，测试出了一些bug并及时修复。

5. 发布阶段：

   • 软件发布可先使用小范围发布，在验证基本可用之后再推广正式上线。
     在发布之前我们进行的最后一次合并修改引入了在iOS移动端的登录bug，而小范围发布时检查出了这个问题，庆幸没有在正式上线时造成大规模影响致使功能不可用。

6. 维护阶段：

   • 文档交付物的详细程度需要考虑接收方。
     在Alpha阶段的末尾，前后端需要互相部署对方的开发环境便于进行联调。前端对文档的维护相对到位，后端比较粗糙，启动说明、版本确认等必要信息很模糊，前端人员对如何启动后端完全不理解。

个人项目、结对编程、团队项目的心得

个人项目通过阅读学习与提问，让我开始思考一些关于团队合作和实际落地的问题，但是个人思考与现有理论之间存在了一些冲突之处。而通过观察其他成熟的项目，又促使我开始思考成熟的软件与以往课程设计的小打小闹之间差距在哪，要做成这样一个软件又要投入多少精力。

结对编程的体验中我们都对花间小路不了解，从了解背景、理解规则到设计策略，虽然在过程中切身体会到了其中的优势，能够互相监督，快速讨论、调整、修正思路，审查代码，但总觉得有人在旁边看着影响思路，真实的工作环境中也是如此，容易产生心理压力。

团队项目是任务量最大的部分，也是收获最大的。一个真实项目的开展让我体验了完成一款上线软件的大致流程。从选题、需求分析、设计模型到代码编写、联调、发布上线，每个环节都暴露了单打独斗时不会遇到的问题，例如代码合并冲突、接口理解偏差、进度互相阻塞等等，在这些磨合中被迫去找解决办法，也学到了更多。

在整个课程中，课程组都以一种比较严格的眼光要求团队，在选题上尤为明显。这也倒逼我们去接触真实市场，提升自我，尝试新工具、新方法等等。提升工程化能力，获得团队协作经验与真实开发项目经历，是我在软件工程课程中的最大收获。