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

102300220张宇亮 2025-12-25 22:25:21

在协作中成长，在细节中精进

软件工程实践总结

这个作业属于哪个课程	202501福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	完成课程回顾、技术总结与开发模式分析。
其他参考文献	《构建之法》、CSDN 技术社区、团队项目文档等

在协作中成长，在细节中精进
一、课程回顾与总结
1. 成长与抒怀
2. 深入思考的问题
问题一：辅助开发的价值究竟是什么？我是否只是“打杂”？
问题二：文档真的是“形式主义”吗？为什么团队总把文档排在最后？
3. 五个阶段的最大收获
4. 团队项目心得
5. 七大课程目标自评（百分制）
二、个人技术总结
三、软件开发模式
1. 项目开发过程
2. 软件开发模式分析
优点：
缺点：
3. 软件开发模式对比与建议
模式选择建议
4. 个人思考

一、课程回顾与总结

1. 成长与抒怀

这门软件工程课是我大学以来最具颠覆性的一次学习体验。过去，我习惯把“完成功能”等同于“项目成功”——只要代码能跑、结果正确，就算大功告成。然而，这门课通过真实团队项目彻底重塑了我的认知：“能跑只是起点，可靠、可维护、可协作才是终点”。

在项目开发中，我作为辅助开发，没有负责核心业务逻辑的编码，却前所未有地深入理解了“质量内建”（Quality Built-in）的含义。我参与了从需求澄清、接口验证、边界测试到文档整理的完整流程，逐渐意识到：一个真正可用、可靠、可持续演进的系统，70% 的功夫不在“写”，而在“想”和“验”。

我虽然没写核心业务逻辑，但通过测试、文档、边界 case 梳理，我第一次感受到“质量不是测出来的，是设计出来的”。

2. 深入思考的问题

问题一：辅助开发的价值究竟是什么？我是否只是“打杂”？

初始困惑：
项目初期，我一度担心自己的角色边缘化。主开发在写 UploadRule、ReviewEvent 这些核心接口，而我似乎只在“跑测试”，“写文档”，“整理随笔”——这些工作看起来琐碎、重复，甚至“可有可无”。

厘清过程：
我的认知转变始于一次真实的 bug 发现。
在测试“管理员查看学生材料”接口时，主开发的逻辑是：根据前端传入的 college 参数过滤数据。我立刻意识到风险：如果恶意用户传入其他学院 ID，是否能越权查看？于是构造测试用例，果然绕过了权限控制。这个漏洞被及时修复，并推动团队确立新规范：所有涉及数据隔离的接口，必须从 JWT 中提取用户所属学院，禁止依赖前端传参。

此外，在整理“积分规则查询”接口文档时，我发现 Thrift 定义的字段是 recognized_event_id，而 Go 结构体生成的是 RecognizedEventID。虽然 hz 工具自动加了 json:"recognized_event_id" 标签，但前端若按 Go 字段名调用会失败。我标注并同步给前端同学，避免了前后端联系的冲突。

新理解：
辅助开发绝非打杂。我们从外部视角、用户视角、攻击者视角审视系统，暴露主开发者因“沉浸式编码”而忽略的盲区。我们的价值不在于产出多少行代码，而在于让系统在交付前就具备抗脆弱性。

问题二：文档真的是“形式主义”吗？为什么团队总把文档排在最后？

初始认知：
在以往课程项目中，我们往往在 deadline 前几小时草草拼凑一份“接口列表”，内容多为 GET /api/user 返回用户信息。我认为“代码即文档”，只要结构清晰，别人能看懂。

转变契机：
在冲刺第三天，团队要联调“ES 全文搜索”功能。主开发实现了 SearchItems 接口，但未说明：

（1）哪些字段支持模糊搜索？（赛事名称、主办方）

（2）ID 查询是否精确匹配？

（3）时间格式要求？

前端同学按经验传了 eventName，但实际字段是 RecognizedEventName（来自 Thrift）。双方花了近 2 小时排查，最终发现是命名风格不一致导致。那一刻我意识到：没有文档的接口，极易导致冲突。

行动与收获：
我主动提出：每完成一个接口，立即生成标准化文档草稿。借助 AI 技术员，我根据 Thrift IDL 和 Hertz 路由注解，自动生成包含以下内容的接口说明：

路径与方法，请求参数（字段名、类型、是否必填、示例），响应结构（成功/失败），典型错误码

主开发采纳后，后续接口联调效率显著提升。

结论：
好的文档不是负担，而是协作的“契约”。它让团队成员在不同时间、不同角色下，对系统有统一认知。

3. 五个阶段的最大收获

阶段	收获最大的知识/能力	具体说明
需求阶段	从模糊表述中提炼可验证的验收标准	例如“辅导员只能看本院学生” → 转化为“所有查询接口自动注入 `college` 过滤，且拒绝前端传参覆盖”
设计阶段	理解权限模型需贯穿数据层到接口层	权限不能只靠前端隐藏按钮，必须在 Service 层强制校验，DAO 层注入条件
实现阶段	掌握 Thrift IDL与Go模型的映射细节	理解 `hz` 工具如何处理 `optional`、命名转换、嵌套结构，能快速定位字段不一致
测试阶段	学会设计“破坏性测试用例”	不仅测正常流程，更测：空值、超长字符串、负数、不存在的 ID、越权参数等边界场景
发布阶段	掌握部署清单的关键要素	明白一个系统上线不仅需要二进制文件，还需：数据库迁移脚本、ES 索引初始化、环境变量配置、健康检查端点

4. 团队项目心得

本次团队项目让我深刻体会到：软件工程的本质是“降低协作成本”。

角色互补：主开发梁伟彬专注构建系统骨架（如积分计算引擎、ES 同步逻辑），我则聚焦验证地基是否牢固（如权限，边界，文档）。这种分工让团队效率最大化。

信息透明：我们通过每日 15 分钟站会，只同步三件事：昨天做了什么、今天计划做什么、当前卡点是什么。这确保问题不过夜。

工具赋能：我们用 AI 技术员统一随笔格式、生成文档草稿、梳理测试用例，将重复劳动自动化，把人力留给创造性工作。

最让我感动的是，主开发从不认为我的反馈是“挑刺”，而是真诚欢迎每一个能提升系统健壮性的建议。这种开放、信任的协作氛围，是项目成功的关键。

5. 七大课程目标自评（百分制）

目标	自评分	详细解释
目标1：职业道德与社会影响	85	通过设计“辅导员仅看本院”功能，理解了软件对教育公平的影响；但在更广泛的社会文化影响（如数据隐私、算法偏见）上思考不足
目标2：需求分析能力	80	能参与需求澄清并转化为验收标准，但未主导需求建模；对“用户故事”到“接口定义”的转化流程还需系统学习
目标3：软件开发全过程	75	理解分层架构（Controller-Service-DAO），但未参与核心设计；对“数据一致性”“事务边界”等有认知但实践较少
目标4：技术评测与创新	70	参与了 ES vs DB 搜索的讨论，但未主导技术选型；创新意识体现在“结构化驳回原因”建议上
目标5：文档规范与交流	90	最大收获：掌握接口文档、部署手册、测试用例的工业级写法，能与业界标准对齐，显著提升团队协作效率
目标6：团队协作能力	88	有效与主开发协作，主动暴露问题并提供解决方案；但缺乏组织协调经验（如任务分配、进度跟踪）
目标7：项目管理能力	72	了解敏捷冲刺节奏，能估算个人任务工时；但未参与整体工作量估算、风险评估、工具配置（如 Jira）

二、个人技术总结

在“准备篇”中，我为自己制定了学习路线：深入 Go 后端开发，掌握 API 测试与接口验证。本次团队项目中，我担任辅助开发，主要解决以下技术问题：

（1）验证 Hertz 接口参数绑定与校验逻辑

（2）梳理 Thrift IDL 与 Go 模型的字段映射一致性

（3）设计破坏性测试用例并推动修复

我选择以下技术进行深入总结：

[个人技术总结: Go + Hertz 框架下基于 Thrift IDL 的接口测试与字段映射一致性验证](个人技术总结：Go + Hertz 框架下基于 Thrift IDL 的接口测试与字段映射一致性验证-CSDN社区)

概述：
在 CloudWeGo Hertz 项目中，Thrift IDL 是前后端接口契约。hz update 工具根据 IDL 生成 Go 结构体、路由和绑定逻辑。然而，因命名风格（IDL 蛇形 vs Go 驼峰）、可选字段（optional）、嵌套结构等差异，极易出现“字段存在但无法绑定”或“前端传对字段却收不到值”的问题。本文总结如何通过自动化比对与结构化测试，确保 IDL 与实现层字段映射 100% 一致。

三、软件开发模式

1. 项目开发过程

项目目标：开发高校竞赛积分认定系统，支持学院/专业管理、赛事认定配置、学生材料提交、管理员审核、积分自动计算、学院/全校排行榜、ES 全文检索、用户反馈查看。
技术栈：Go 1.22 + CloudWeGo Hertz + MySQL + Elasticsearch (olivere/elastic/v7) + JWT + Thrift IDL
关键决策：
- 接口契约：采用 Thrift IDL，确保前后端字段、类型、必填性一致
- 权限模型：辅导员角色通过 JWT 透传 college，Service 层统一注入过滤条件
- 积分计算：Beta 阶段采用“审核通过即同步计算”，优先保证闭环，标记后续优化为异步
- 数据同步：认定事件变更时，手动调用 ES AddItem/RemoveItem，并记录后续需引入 MQ 保证一致性
挑战与解决方案：
- ES 与 MySQL 数据不一致风险 → 在 Service 层关键路径显式调用 ES 同步，并添加错误日志
- 权限越权漏洞 → 禁止前端传 college，所有过滤基于 JWT 解析结果
- 驳回理由无法统计 → 提议后续增加 reject_reason_type 枚举字段

2. 软件开发模式分析

我们采用 Scrum 敏捷开发，具体实践如下：

每日站会：15 分钟同步进展、卡点，不讨论细节
任务拆解：按“接口 + 测试 + 文档”三位一体拆分，主辅开发结对协作
持续交付：每日结束时确保当日功能可演示、可测试

优点：

快速反馈闭环：问题在当日暴露、当日解决，避免堆积
聚焦用户价值：优先实现“认定→审核→积分”核心链路
角色灵活互补：辅助开发可快速切入测试与文档

缺点：

技术债显性化：如 ES 一致性、驳回原因结构化等问题被标记“后续优化”，若无迭代计划易被遗忘
文档初期滞后：初期未同步更新接口说明，导致联调阻塞
测试覆盖不全：因时间紧张，仅覆盖主路径和关键边界，未做全量异常测试

3. 软件开发模式对比与建议

开发模式	核心思想	优点	缺点
瀑布模型	按顺序一步步做：先定需求，再设计、编码、测试，不能回头改。	流程清晰，文档全，适合需求稳定的项目。	不能改需求，改了成本高；问题发现晚；用户参与少。
快速原型模型	先做个简单可运行的 demo，让用户试用后再正式开发。	快速验证想法，用户反馈早，需求更准。	容易忽略文档；用户老想加新功能，项目容易失控。
增量模型	把系统拆成几块，一块一块做，每块都完整可用。	能先上线核心功能；风险分散；变更影响小。	拆不好会出兼容问题；对架构设计要求高。
螺旋模型	每次开发都先分析风险，再做一小部分，反复循环。	风险控制强，适合复杂、高风险项目。	流程复杂，耗时长，小项目用不划算。
敏捷开发	小步快跑，每1–4周交付一次可用功能，随时响应变化。	灵活、响应快；团队协作好；产品更贴近用户。	需要团队能力强；文档容易缺失；大项目管理难。
迭代模型	分多个版本逐步完善，每次功能比上次多一点。	问题早发现；用户能持续参与；适合渐进优化。	需要前期规划好；迭代边界不清容易混乱。