OO第三单元总结

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

在我的OO学习中，我感觉JML语言更像是一种“约定”，或者是一种“契约”。比如是在小组分工完成的场景下，一个人按照自己的开发留下了接口，而另一个人就需要实现这个接口完成。JML与规格开发可以让前后两个人形成“约定”，按照前者留下的描述实现代码的过程，就像是一种“履行契约”的行为。对团队的大规模开发来说就如“统一度量衡”，用统一的JML语言划分好边界。

JUnit测试的经验

我在第一次做JUNIT测试时卡了很多次过不了，后来问过了的朋友了解到他采用了一种“镜像”的方法，我按照这种思想改了一版提交上去马上就过了。总结下来，本学期的JUNIT测试与上学期的不同，上学期的看重测试的覆盖率，我那时候通过“伪测试”，就是预制好输入流（从中测里随便借一段样例）来保证覆盖率。而这学期的则是与JML相关，要通过镜像来保证JML中的前置、后置条件是否满足，要防止篡改数据。只要保证做好镜像，以及测试覆盖所有要求即可

三次作业的迭代过程

三次作业的宽度不大，第一次是初步建立视频网站的框架，第二次是增加投币点赞等功能，第三次是引入了类似”推流“的功能，做了一个相对完整的”推送“、”热度榜“的功能。只要按照接口中的JML一个一个补充方法就行，其中务必注意性能。关于容器的变化，我是利用AI来辅助查找的，我提示AI在迭代过程中可能有容器或方法有些许变化让AI来帮我查找。而关于性能瓶颈的话，我认为选择一个优秀的容器可以最大程度降低性能问题的可能性，其次是选择合适的算法，比如堆排序，双向BFS等优秀方法来降低时间复杂度。

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

我出现的BUG就是容器没有选对，我在最初建立框架是大量使用的ArrayList容器，但这样一会导致查找时间长，二是无法自动去重，使代码崩溃风险提高。

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

我使用的是Genimi3.1Pro，在JML编程时确实会忽视效率问题，但不会忽视架构容器问题。感觉AI会在效率上尽可能偷懒，明明有缓存的方法，他第一次生成时多半不会使用，必须自己提示AI才有可能避免。此外就是刚觉AI会尽可能想用更短的代码来完成任务，比如可以采用全局变量的方法来记录互关数目，但AI一定要采用O(N^2)的方式遍历，甚至我和我一个也是使用Gemini的朋友的AI都不约而同的使用了双重遍历来计算粉丝数，而这个恰好会在第一次时导致几个强测数据无法通过。