OOUNIT3博客总结

[吕明康-24231213]

Unit3总结

对 JML 与规格驱动开发的理解

JML 是把需求写进代码的契约语言。它依赖javadoc注释，而是可被理解与验证的行为边界：

• JML 让“输入约束、输出保证、状态保持”显式化，避免只靠口头和经验推断功能。
• 规格驱动开发强调“先规格后实现”，实现要围绕不变式与前后置条件展开，而不是先写代码再补说明。
• JML 中常见的陷阱是把“实现细节”写成规格，或者忘记描述边界/异常情形，导致实现与测试都失焦。

对我而言，规格驱动开发最大的价值是：根据课程组的官方包理解需求，让我在写代码之前就把必须成立的条件搞清楚。

JUnit 测试经验

JUnit 的核心作用是把规格转化为可反复执行的断言。我的经验主要有以下几点：

• 用“规格切片”设计用例：为每条关键 JML 约束设计一组正向与反向样例。
• 断言不仅验证返回值，还要验证异常类型、异常计数和对象状态的保持。
• 边界测试要覆盖：空集合、最小/最大 id、重复操作、无效引用等。
• 采用“先写测试，再补实现”的顺序时，最容易暴露规格理解偏差。
• 对容易被忽略的副作用写测试，例如“对象之间的双向关系是否保持一致”。

三次作业迭代过程与变化发现

这三次迭代在代码里主要有容器变化，功能新增，计算口径变化三个方面：

• hw9 是最基础的社交/视频模型：Network 用 ArrayList 维护用户与视频，getUser/getVideo 都是线性扫描。User 的“待看视频”是 ArrayList，Video 只有 id 与 uploaded。

• hw10 的核心变化是“数据结构升级 + 功能扩展”：Network 改为 Map 存储用户/视频，避免线性查找），新增类型校验与视频类型字段。功能上补齐了观看、点赞、投币、转发、评论、清理垃圾评论与“最热视频”等接口，以及“勋章购买”“最长下降序列”两个新需求。User 侧新增 coins、watched/liked、contributor/medal 等结构，Video 侧新增热度、评论与 KMP 清理逻辑。

• hw11 的重点是“推荐与画像”：upload 时记录上传者的视频集合，User 侧新增 watchedVideos/uploadedVideos 与类型计数，支持兴趣、影响力、画像与评分计算。Network 新增全局最佳贡献者、视频推荐、Up 推荐与影响力查询。另外热度计算公式也从 hw10 的 double 权重改为 hw11 的整数权重。

这类变化我主要靠两种方式发现：一是对比新增/修改接口，二是“找容器/计算口径变化”。比如 users 从 ArrayList 变成 Map、receivedVideos 从 ArrayList 变成 Deque，这些变化往往意味着复杂度与语义都在变。

如何发现性能瓶颈

这三次作业隐藏的要求就是算法时间复杂度在O（n^2)以内，否则强测会出现超时问题，性能相关的变化在这几处最明显：

• hw9 的线性查找在用户/视频数量增大时会退化，我在 hw10 直接改为 Map 以降低查找复杂度。
• “收到视频列表”从 ArrayList 变为 Deque，配合头插更自然，也避免频繁的整体移动。
• 垃圾评论清理采用 KMP 计数，避免在长文本上反复回溯。
• hw11 的推荐评分需要遍历所有视频/用户，但将“兴趣/影响力”拆成可复用计算，降低了重复计算的逻辑复杂度。

典型 bug 与原因分析

我最容易出 bug 的点主要集中在“重复元素处理”和“新统计口径”两类：

• receivedVideos 的删除逻辑：hw9 只删除第一个命中，在 hw10/11 我改为删除所有出现以贴合“已观看视频不应再出现”的语义。这类 bug 本质是对“重复性”的理解不够严格。
• 统计口径变化：hw11 的热度公式调整和推荐相关的兴趣/影响力计算容易导致“旧逻辑沿用”的错误，需要我在实现前先把公式和数据依赖关系搞清楚。
• 新增关系维护：例如 upload 时需要同步维护上传列表，漏掉就会直接影响推荐结果。

JML“击鼓传花”游戏的感悟

这次活动让我直观感受到“规格传递时的信息损耗”：

• 很容易在转述时遗漏边界条件或异常约束，导致实现偏差。
• 需求在传递过程中会被“简化”或“想当然”地补充，从而改变了原意。
• 我也在别人的规格里发现过逻辑漏洞，例如前后条件不一致、遗漏异常场景等。

如果未来多人协作，我认为需要：

• 统一规格模板（前置/后置/不变式/异常）与命名习惯。
• 在实现前做一次“规格走查”，把边界条件逐条确认。
• 为关键接口建立共享测试用例，作为规格解释的“可执行证据”。

这会显著降低团队成员之间的信息差。

使用大模型的体会，Code Agent 使用经验

在 Unit3 使用了大模型GPT-codex5.2的agent模式辅助，我的体会是：

• AI会严格根据JML生成代码，一般没有逻辑性错误。
• 风险在于AI可能会不考虑性能，忽略效率与容器结构，给出“能跑但慢”的实现。
• 用大模型做基础单元测试时，AI很难将JML要求检查全面，会出现场景覆盖不全的问题。
• 运用agent模式，在提示词中讲清楚依赖的代码文件或文件夹，再结合当前工作区，准确率比使用网页端高得多。