软件工程实践总结&个人技术博客

062300144吴毅鹏 2025-12-25 21:02:58

这个作业属于哪个课程	2025福大软件工程实践W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	回顾课程全生命周期、总结个人技术突破、深度思考软件开发模式
其他参考文献	《敏捷软件开发：原则、模式与实践》《软件工程：实践者的研究方法》

第一部分：课程回顾与总结
一：深入思考的问题与解答
问题一：测试输出不确定的AI组件——从“是与非”到“概率评估”
问题二：避免成为团队瓶颈——从“终点质检员”到“流程共建者”
二：五个阶段的收获
三：理解与心得
四：课程目标掌握程度自评
第二部分：个人技术总结
个人技术博客
第三部分：软件开发模式
一.项目开发过程
二、软件开发模式思考
1、项目采用的敏捷开发模式分析
2、敏捷开发的优缺点及影响
3、不同开发模式对比
4、我的思考与建议

第一部分：课程回顾与总结

一：深入思考的问题与解答

问题一：测试输出不确定的AI组件——从“是与非”到“概率评估”

尝试解答的“坑”：
起初，我编写了一个如 assert(parse("奶茶20元") == {"category":"餐饮", "amount":20}) 的测试用例。结果发现，AI可能返回 {"category":"饮品", "amount":20}。在传统框架下，这被判定为“失败”，但实际上AI的理解在业务上是可接受的。我的测试框架在频繁“误报”中失效。
继续分析的具体步骤：
1. 重新定义“正确”：我与产品、开发共同制定了一份“业务等价类”映射表。例如，{"奶茶","咖啡","饮品"} 均映射为 "餐饮" 大类。测试断言从严格的相等，变为“检查结果是否在可接受集合内”。
2. 引入量化评估体系：
  - 构建基准数据集：从生产日志中匿名采样了500条真实用户输入，并由三人小组标注出“标准答案”。这成为我们的黄金测试集。
  - 设计评分脚本：不再输出“通过/失败”，而是每次回归测试后自动计算精确率和召回率。例如，我们发现AI对“交通罚款”的分类召回率低，因为它常被误认为是“行政缴费”，这指引我们补充了相关训练数据。
  - 设定基线与预警：以第一轮测试的F1分数（85.2%）为基线。后续任何一次自动化测试若分数低于80%，或连续三次下降，就会自动触发警报，而非阻塞发布。
3. 分离测试维度：我将测试分为能力测试（用黄金集评估模型能力是否下降）和集成测试（验证服务是否正常响应、格式合规）。这样，当集成测试失败时，我们能快速定位是工程问题而非模型问题。
新的具体问题：
1. 黄金测试集本身如何长期维护？随着业务变化（如新增“宠物支出”类别），如何低成本地更新标注集？
2. 如何设计一个“压力-稳定性”测试，持续向AI服务发送带有模糊性的请求（如“花了些钱”），观察其响应是否会崩溃或产生极端不合理的输出？

问题二：避免成为团队瓶颈——从“终点质检员”到“流程共建者”

尝试解答时的具体困境：
在V1.0版本，我在集成阶段报告了47个Bug。其中超过30个是“接口字段缺失/命名不一致”、“未处理空数组”等低级契约问题。修复它们花了3天，重新测试又花2天，项目延期，团队弥漫着“都是测试太慢”的抱怨。
继续分析的具体行动：
1. 设计阶段介入（左移）：在API设计评审会上，我不再沉默。我会具体提问：“这个‘金额’字段，前端传的是分还是元？如果传负数，代表收入吗？”并推动将结论写入 《API契约文档》 ，该文档成为后续开发和测试的唯一依据。
2. 开发阶段并行验证：
  - 契约测试：使用 Pact 工具，依据《API契约文档》自动生成Mock服务和测试用例。后端同学开发完接口，立即运行契约测试，能独立验证其实现是否符合契约。
  - 共享测试夹具：我编写了用于生成测试数据（如模拟用户、账单）的共享代码库，前后端开发都可以调用，确保测试数据的一致性。
3. 建立可视化质量门禁：我在团队看板上创建了“接口就绪状态”面板。每个接口都有四个状态：设计已评审、契约测试通过、集成测试通过、性能测试通过。任何进度的阻塞都一目了然，责任不再集中于测试环节。
新的具体问题：
1. 如何衡量“左移”的ROI？我能否统计出：在设计评审中每投入1小时，平均能减少后续多少小时的缺陷修复时间？需要建立怎样的数据追踪模型？
2. 当团队引入新技术栈（如GraphQL）时，原有的基于REST的契约测试流程如何快速适配？谁来主导建立新的质量保障规范？

总结的具象化成长：
我从一个仅会执行测试用例、在终点线挥舞红旗的裁判，转变为一个在起跑线就与队员一起检查装备（设计评审）、在训练中提供标准靶子（契约Mock）、并通过实时数据看板（质量状态）服务整个团队的质量工程师。我的工具从单一的测试脚本，扩展为契约文档、自动化Mock、共享测试工具和可视化看板这一套组合体系。

1. 需求阶段：获得“翻译与提问”的能力
最大的收获是意识到需求不是被给予的，而是被发掘和定义的。我学会了用“业务目标五问法”追溯表面需求背后的真实问题。例如，当产品提出“需要一个更精准的记账分类AI”时，通过提问我们明确其核心痛点是“用户因分类不准而放弃应用”，从而将需求重点从“提升算法精度”修正为“在分类不准时提供流畅的纠错体验”。这让我深刻理解，明确一个问题的边界，比急于寻找解决方案更重要。

2. 设计阶段：理解“文档即契约”的工程意义
我过去认为设计文档是“参考资料”。在实践中，我最大的收获是认识到清晰的设计文档（特别是API契约）是一个具有约束力的多方协议，是后续所有并行工作的基石。在一次因接口字段歧义导致的重大返工后，我们强制推行了使用OpenAPI规范编写契约，并通过工具自动生成Mock Server和客户端桩代码。这使前后端、测试得以在无实际代码时并行工作，将设计阶段的歧义消灭在编码之前。

3. 实现阶段：掌握“为可测性而设计”的实践
收获最大的是 “可测试性”应作为编码时的核心设计考量之一。例如，在实现记账服务时，我会有意识地将“AI模型调用”、“业务逻辑处理”、“数据持久化”三者严格分离。通过依赖注入，在测试时可以将不稳定的AI组件和数据库替换为Mock。这使得单元测试可以快速、独立地运行核心逻辑。我认识到，易于测试的代码，其模块化、松耦合的程度也更高，本身就是更健壮的代码。

4. 测试阶段：构建“分层评估与防护”体系
面对AI系统的不确定性，我最大的能力提升是 从“确定性断言”思维，转变为“分层评估与监控”的体系构建思维。我不再追求单个测试用例的绝对通过，而是建立了：单元测试层（验证确定性逻辑）、集成契约层（验证服务间约定）、统计评估层（用黄金数据集评估AI效果）、混沌实验层（验证系统韧性）。测试活动从“找Bug”演变为为系统不同层面的质量特性提供持续、量化的证据。

5. 发布阶段：建立“发布即开始”的运维视角
最重要的认知转变是：代码部署上线并非终点，而是真实价值验证和持续优化的起点。我学会了在发布前就必须规划好“可观测性”方案：在关键链路上埋点，定义核心业务指标（如“记账成功率”）、性能指标和错误告警。首次发布后，我们通过监控发现，凌晨时段“扫码记账”的失败率异常高，经排查是网络依赖服务不稳定，从而快速增加了重试机制和降级方案。这让我深刻体会到，没有度量与监控的发布，无异于在黑暗中航行。

总结而言，“做中学”让我领悟到，软件工程的核心知识点并非孤立存在。它们贯穿于从精准定义问题、到用契约锁定设计、为实现可测性编码、建立分层质量防护、直至最终通过数据驱动持续优化的完整闭环中。每个阶段的关键能力，都是确保这个闭环能够可靠、高效运转的必需齿轮。

三：理解与心得

个人项目
在个人项目中，我主要专注于学习C++后端与前端开发的基础知识。虽然最终没有在团队项目中使用C++，但这个过程让我：
1.理解了后端开发的基本概念（HTTP协议、数据库操作、API设计等）
2.培养了自主学习的能力
3.为后续学习其他技术栈打下了基础
团队项目
在团队项目中，我担任测试的工作，这让我：
1.理解了团队协作的重要性
1.1每个人都有自己的专长和角色
1.2有效的沟通是团队成功的关键
1.3文档和规范的重要性：清晰的接口文档让前后端协作更顺畅
2.体验了真实的开发流程：
1.从需求分析到最终上线的完整流程
2.版本控制和代码管理（Git）
3.问题跟踪和任务分配
核心心得：
软件工程，本质上是一门关于多人协作以持续、可靠地构建并维护复杂系统的学科。个人项目教会我独立解决问题的韧性；结对编程让我深刻体验到实时沟通、即时反馈和共同所有权的重要性；而团队项目则像一场全景模拟，让我真正理解了从需求到运维的全生命周期中，规范、契约、透明度和可观测性是如何成为维系多人协作、降低认知负荷、保障系统稳定的基石。最大的转变是心态：从一个只想写好自己代码的工匠，成长为一个关心价值流动、关注团队效能、守护系统健康的工程师。

四：课程目标掌握程度自评

目标1：职业道德与社会影响理解【85/100】

评分依据：在项目需求分析中，我始终将“用户体验”和“社会影响”作为核心考量。例如，在AI记账项目中，我们主动讨论并规避了可能因分类偏见（如将“母婴用品”简单归类为“女性消费”）带来的负面社会影响，并在设计纠错流程时强调包容性。我理解软件工程师负有建设性责任，但在更广泛的国情社情、行业伦理规范（如数据隐私法规的深度应用）方面，仍需更多系统性学习。
实践例证：在决定AI模型失败时的降级方案时，我们优先选择了引导用户手动分类，而非强行提供一个可能错误的自动结果，以维护用户信任和数据的准确性。

目标2：需求分析与建模能力【90/100】

评分依据：通过多次需求评审会与场景化分析，我熟练运用了“提问-溯源-建模”的方法。我能有效辨别客户的表面需求与深层目标（如将“精准分类”转化为“顺畅的记账体验”），并使用用户故事、业务流程图及精细化的业务规则映射表（如分类等价类）来规范、准确地表达与建模需求。在复杂业务规则的抽象与梳理上，我已具备扎实的实践能力。
实践例证：主导梳理了“转账-报销”混合场景的复杂需求，并用清晰的流程和状态转换图与产品、开发达成一致，避免了后续的理解歧义。

目标3：全过程开发与设计能力【88/100】

评分依据：我完整经历了从架构设计（前后端分离、微服务组件划分）、数据设计（数据库表结构、缓存方案）到构件级设计（API接口、可测试的模块）的全过程。严格遵守了接口契约先行、依赖倒置等设计原则，并通过正式的技术评审（如API设计评审会）来确保设计质量。扣分点在于，对于超大型系统的架构模式（如事件驱动架构）实践经验尚浅。
实践例证：在团队项目中，我主导设计了“智能记账核心服务”的组件级方案，通过清晰的接口定义和高内聚模块划分，使其能独立开发、测试并被其他服务稳定调用。

目标4：技术评测与创新设计能力【87/100】

评分依据：我系统性地建立了从组件单元测试、集成契约测试到系统级统计评估（如AI模型F1分数监控）的多层次技术评测体系。具备对设计模型（如不同缓存策略）的评判和优选能力。在解决AI输出不确定性问题时，创新性地引入了“概率评估”和“黄金数据集”的持续监控方案。在探索前沿技术（如GraphQL替代REST）进行架构创新的实践经验上，尚有提升空间。
实践例证：通过设计A/B测试对比了两种不同的错误处理方案，最终用数据（用户留存率提升）说服团队采用了体验更优的“渐进式引导”方案。

目标5：规范文档与交流能力【89/100】

评分依据：我深刻理解并实践了“文档即契约”的理念，熟练使用Markdown、Swagger/OpenAPI等工具，规范撰写了API接口文档、模块设计说明及系统测试报告。在团队中，我能通过清晰的文档和图表与不同角色成员进行高效交流。日常技术讨论和评审会议中的表达已较为规范、准确。
实践例证：我编写的API文档被前后端开发共同视为唯一真理源，并基于此自动生成了Mock Server和客户端代码，极大提升了协作效率。

目标6：团队协作与组织能力【90/100】

评分依据：在结对编程中锻炼了实时沟通与协同；在团队项目中，我主动承担了质量保障体系的建设和协调工作，能够与产品、前端、后端、算法同学进行有效沟通与协作。我能够组织技术评审会议，并协调各方对方案达成共识。在冲突处理和多团队并行协作的更高阶组织技巧上，仍有成长余地。
实践例证：当集成测试因接口变更频繁失败时，我主动召集了简短的站立会议，快速定位问题根源（缺乏变更同步机制），并推动建立了接口变更通知清单，解决了团队协作瓶颈。

目标7：项目管理初步能力【75/100】

评分依据：我能够辨别项目管理中的核心要素（范围、进度、质量、沟通），并在团队项目中实践了基于任务拆解的工作量估算，使用看板工具（如GitHub Projects）可视化跟踪进度，进行简单的过程配置（如定义“完成”标准、代码合并流程）。然而，对于复杂的规模估算方法（如功能点分析）、风险管理的系统化实践，以及多项目并行的资源规划，仍处于初步了解和尝试阶段，这是主要的扣分项。
实践例证：负责本组“智能记账”模块的项目管理，通过拆分任务、估算工时并每日同步阻塞风险，确保了该模块在预定迭代周期内高质量交付。

第二部分：个人技术总结

个人技术博客

概述：微信小程序自动化集成测试框架是针对大学生个人记账小程序的组件交互、数据流、API接口进行全面验证的技术方案。作为连接测试工程师，我选择miniprogram-automator作为核心技术，因为它能模拟真实用户操作，验证小程序各模块间的数据流和状态一致性。技术难点在于异步操作同步、页面跳转时机控制、微信API模拟以及测试环境与生产环境的隔离。