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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2025_LR/homework/13465
我在这个课程的目标是	学习较为完整基础的软件开发流程，以及如何在软件工程中进行良好的团队协作
这个作业在哪个具体方面帮助我实现目标	思考并解决学期初提出的关于软件工程的几个问题，并总结一学期所学内容

提问题博客链接

https://www.cnblogs.com/7111-lyh/p/18756800

回答以前的问题，并谈谈收获与新的思考

在第一篇个人博客中，我提出了五个与软件工程学习与实践相关的问题。随着课程的深入、阅读教材、参与小组项目以及与同学的讨论，我对这些问题有了更加具体和深入的理解。下面我将逐一进行回应，并分享我在思考和实践中的收获。

关于“如何更好地理解软件开发过程中的服从性难题”的问题

我起初的理解是：软件必须适配硬件、系统与行业要求，这种对外部环境的“服从”限制了其自由。这种理解是对的，但仍不够全面。通过阅读《构建之法》中关于服从性的描述和在项目中处理接口兼容、部署环境适配的问题后，我意识到服从性不仅仅局限于硬件适配，更包含合规性（如隐私法规、行业标准）、运维限制、以及组织流程本身带来的边界。

例如，在我们项目部署过程中，服务器配置、安全策略等运维要求对我们的架构设计提出了现实约束，而我们不能只从“技术角度”出发。再如，当涉及用户数据时，我们需要主动查阅相关的数据合规法律。这些让我体会到服从性是“软件外部世界”的映射，是工程实践中必须面对的“现实规则”，需要用“工程思维”而非“编程思维”来应对。

关于“结对编程在某些情况下可能存在的问题”的思考

我曾担心结对编程中水平不对等会影响效率，比如水平高的一方进度变慢，而水平低的一方又难以提供实质性帮助。在一次项目开发中，我们团队尝试了“按功能点拆分+轮流结对”的策略，避免了“强带弱”的极端情况。结对时也不是强制每个任务都一起做，而是在功能调研、测试用例设计、系统集成等环节中交叉合作，这种做法更灵活，也更适合实际情况。

同时，在和队友的沟通中，我意识到：关键并不是两人水平完全一致，而是建立“知识对称”的沟通机制。比如让水平高的一方负责解释设计原理、带动思路，而不是“代替完成”，这样才能实现共同成长。因此，我现在认为，结对编程的效果取决于机制设计，而非单纯的人员水平配对。

关于“保持敏捷但不要过早泛化”的思考

在项目初期我们遇到过类似“过早设计”的问题：为了应对可能未来的“复杂场景”，我们设计了大量预留接口和抽象结构，但后期实际根本没用上，反而增加了维护成本。课程中提到的“变化总是会来，但不是你想象中的那种”这句话给我很大启发。

真正的敏捷不是“提前适应一切变化”，而是让系统在变化发生时能够快速、平滑地调整。这让我理解了“拥抱变化”与“避免过早设计”之间的平衡点：要为变化留出空间，而不是替未来做决定。我们在后续迭代中采取了“YAGNI”（你不会需要它）原则，更专注当前功能，等变化真正到来再应对。这也让我认识到“灵活性”不是复杂结构的代名词，而是修改成本可控的设计目标。

关于“NABCD分析方法的补充和完善”的思考

通过课程与实践，我越来越认可用户反馈在产品迭代中的重要性。课本中虽然介绍了NABCD方法，但在实际项目推广后，我们深刻体会到“D（Delivery）之后的效果如何”才是关键。在产品第一次内测后，我们收集了大量用户反馈，并对UI、流程、交互逻辑等做了多次优化。

因此，我提出在NABCD后增加一个E（Evaluation）阶段，用来系统性地评估用户使用情况、采集反馈数据，从而完善产品。这也和PDCA循环中的“Check”阶段呼应：做得再好的产品，如果没有持续评估和迭代机制，也难以持续成功。所以我现在倾向于把NABCD升级为NABCDE模型，更加符合软件持续演进的现实。

关于“效能测试、负载测试、压力测试三者的异同”问题的理解

最开始我觉得这三者界限模糊，因为它们都涉及“用户数”和“响应时间”。但通过读教材和查阅相关资料后，我意识到它们的目标和适用场景是不同的：

效能测试：强调在正常业务负载下的性能指标。

负载测试：逐步提高用户量，找出系统性能瓶颈。

压力测试：模拟极端情况测试系统稳定性。

虽然它们都涉及“负载”，但重点不同。实践中我们在系统上线前分别进行过负载测试（找最大并发数）和压力测试（看在高负载下会不会崩溃），这让我理解了为什么书中强调“压力测试并不属于效能测试”，因为它测的不是性能，而是极限和稳定性。但三者又可以被纳入“性能类测试”的大类中。从实践来看，分别定义它们能帮助团队更精准地测试和评估系统。

在项目六大阶段中，我分别学到了什么知识点？

1. 需求阶段：明确用户需求
   学会了通过用户画像和使用场景分析，抓住用户真正需要解决的问题。

2. 设计阶段：模块划分与接口定义
   理解了将系统拆分为独立模块的重要性，提前定义好接口能减少后期返工。

3. 实现阶段：版本控制与协作开发
   掌握了使用 Git 进行多人协作开发的方法，避免了代码冲突和丢失。

4. 测试阶段：边界测试与用例设计
   知道了不能只测“正常情况”，边界测试能更早发现潜在问题。

5. 发布阶段：灰度发布降低风险
   学到了“先小范围上线、再逐步推广”的方法可以降低发布失败的风险。

6. 维护阶段：基于反馈的持续改进
   明白了上线不是终点，要根据用户反馈不断修复问题和优化功能

总结：实践中深化理解，问题中发现成长

回顾这些最初的问题，我发现自己对软件工程从“表面理解”走向了“系统认识”。有些困惑是通过课堂讲解理清的，有些则是在项目中踩过坑后才真正明白。而最重要的是，我逐渐学会了用“工程思维”去看待软件开发——它不是简单的代码堆砌，而是一个在多种约束下协调资源、持续交付价值的复杂过程。

虽然还有许多问题没有完全解决，但我已经从一个初学者转变为愿意主动发现问题、反思方法、优化实践的开发者。这门课教会我的，不只是方法与工具，更是一种理性、系统和不断演进的思考方式。软件工程，不只是“写程序”，更是理解人与技术、过程与目标之间的关系。