OO第三单元博客总结

[王若朴-24371127]

OOU3博客总结

总结对JML和规格驱动开发的理解

在接触学习JML的过程中，我感受到了从自然语言定性描述需求 向 特定语言定量描述实现的转变
简单来说，自然语言（指导书）描述的定性需求，即使添加再多的限制条件，也会造成代码理解上的歧义，因为自然语言无法点对点的和代码中的每个变量、函数联系起来
JML作为一种特定语言，可以定量描述每个方法的 前提条件、后置条件、不变量和过程，在方法实现的过程中不会出现歧义，也不会带来不符合期望的副作用
与外置的规格语言相比，JML内嵌在Java中并且支持静态审查，规避了很多冗余操作

很多方法功能关键难点并不在于实现过程，而是实现过程中带来污染数据的副作用，通过JML定量限制可以有效避免

总结JUnit测试的经验

在JUnit测试中，如果只是单纯的覆盖所有分支的测试程序，用LLM可以很轻松的生成所有分支情况，但实际的复杂程序中往往需要测试更复杂的交叉情况，这种情况下大模型生成的静态测试程序覆盖的范围就不够广泛了

人为构造JUnit可以有效解决这种情况，但实际体验上就是人为构造样例，如果我能快速人为构造有效的JUnit测试，其实就不需要显化写出来了，可以直接进入我的代码逻辑里去修复bug，所以我感觉JUnit测试核心功能还是静态测试所有分支

总结分析三次作业的迭代过程。总结如何发现已有方法/容器在迭代中的变化？如何发现程序的性能瓶颈？

在迭代中发生变化的方法，我采用的是让本地agent直接在初始阶段进行一次新JML与旧代码的静态分析，标注出哪些已有方法发生变化，然后结合新JML进行修正，然后再去实现完全新增的方法。
性能瓶颈在三次作业中没太遇到，我的经验是能用效率更高的容器就不用效率的低的

分析自己程序出现过的bug以及Bug出现的原因

在第二次作业的cleanSpam函数中我出现了一个分支未处理的bug，具体bug内容是当清除评论的关键词为空（清除所有评论）时，代码未处理这种情况，出现这种bug的根本原因还是JUnit测试的覆盖率没有覆盖完全，导致漏过了这种分支

如果你在Unit3使用了大模型，可以分享如下内容： 在规格驱动开发时大模型具有什么优势 大模型在根据JML编程的时候，会不会忽视效率问题，会不会忽视架构/容器问题？ 如何用大模型进行基础的单元测试？

我在U3的作业中主要使用的agent，在规格驱动开发中，agent来进行所有方法代码的具体实现，我负责给出架构设计并审查他给出的代码，因此效率和架构问题不会出现大模型不受控制的出现问题的情况

test部分我交给大模型进行尽量全的分支静态覆盖，这个地方我由于疏忽没有进行代码审查，出现了比较严重的问题，这方面给我的警示是使用大模型提高效率是必然，但一定要保证生成的代码在自己的控制之下

Unit3第二次研讨课上，JML“击鼓传花”游戏的感悟： 你是否发现了自己/别人的JML的bug？ 在传递过程中，需求，边界是否发生了变化？ 今后多人组队编程时，你认为怎么做才能统一所有人对任务需求和实现方法的理解？采用什么措施（或者指定规则）可以减少组内成员间的信息差？

在击鼓传花游戏中，我们组出现了自然语言和JML描述不一致的情况，我觉得把JML翻译成代码要比把自然语言翻译成JML要好写的多，在多人组队编程中我认为应该经历 自然语言讨论-> JML规范讨论 -> 代码实现，防止出现不同人在自然语言转化成JML的描述不一致和描述错误