> For the complete documentation index, see [llms.txt](https://minguw.gitbook.io/jvm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://minguw.gitbook.io/jvm/jvm-framework/da-zuo-ye-sheng-cun-zhi-nan.md).

# 大作业生存指南

## 前置要求

好好做完前六次实验理解每一个模块都做了什么，你可以反复阅读[从计算机的视角看待JVM](/jvm/mooc-minilab/view-of-computational-model.md)这篇文章来验证自己是不是真的很明确的理解了模块的作用。

{% hint style="info" %}
想要深入理解一个模块的行为，一个有效的阅读源码的方法是边读边注释。此外，遇到不理解的代码可以试图让它run起来，从动态的角度观察执行流程，或者查看调用关系（sequence diagram）。

因为每一次作业都是以填空的方式完成的，所以很多同学不一定都仔细读过源码中的其他部分。通过各种方法AC了也还是没能获得一个清晰的概念是非常正常的事情。我们建议在开始写大作业前画上两三天把所有的代码都仔细过一遍。

这个过程也能帮助你理清楚框架代码中的优点缺点与各种tradeoff，以便做出更好的设计。
{% endhint %}

{% hint style="warning" %}
（选做）在大作业框架里提供的解析class文件的部分中，有一个非常重要的知识点是“属性的解析“，我们希望你能够了解一下属性表是什么，它能做到什么，这会让你对JVM本身有更好的理解。
{% endhint %}

## 提供给自己更多的有效信息

相信在第五次作业中大家都靠着一个可视化界面和控制台输出相当轻松的就通过了OJ。而在第六次的作业中，我们已经取消了这些辅助工具，也许很多人的debug过程会变得格外痛苦。

那么想必你也体会到了，一个强大的debug工具能够帮助我们在写代码时快速解决问题。

尽管IDEA的debug工具已经提供了十分丰富的支持，但是在面对大量需要定制输出的信息的时候它还是会显得有些乏力。你可以通过一些方法让输出、中间状态变得更可读，例如shell脚本、规格化的printf、log日志或者更强大的前端应用，它们的本质都是过滤掉干扰信息提供更多有效的内容用于debug

## 及时测试

查看[整体实验架构](/jvm/mooc-minilab/lab-design.md)，这是我们推荐的实现顺序（你也可以先留出接口然后按自己喜欢的顺序去实现）。在每一个模块实现后你都应该对已有的模块来进行一定的测试，逐步扩展功能。否则最后很有可能一个bug就能让你崩溃。

> 助教们曾经也合作过非常多的项目，我们在第一次正式合作时采取了大爆炸式集成，简单的说也就是每个人写完了自己的部分然后拼到一起，最后试图一次性把整个系统跑对。结果当然是毫不意外的整个项目都大爆炸了（其中曜铭xgg写的各种bug功不可没（x

不要吝啬花在测试上的时间，我们非常理解那种“我已经花了这么长时间来写了居然还要我测试“的心情。但是测试的用处是巨大的，它能够给你继续推进工作的信心。测试的越充分，埋下bug的可能性就越低，出bug的时候你需要检测的范围也就越小

#### 一些经验

1. 注意好边界条件的测试
2. 当出现if-else的时候尽量设计用例使得不同的分支都能够被执行到
3. junit5比4提供了更好用的接口，可以直接学5，对之后的课程也会有帮助。我们在之前的测试用例里使用4只是因为平台不支持5（
4. 仔细设计用例，免得出现测试用例写错导致把源码也改错的尴尬情况

## 良好的编码风格

1. 多写注释，整个大作业开发周期相对较长，不写注释很有可能中间出去旅游几天回来就看不懂自己写的是什么东西了。另外请谨慎命名，不要使用例如value1，str2这样的不具备含义的名字，或者用中文拼音来命名，这会给你自己回顾代码带来巨大的麻烦。好的代码应该是能够自解释的。
2. 不要让一个方法变得过长，尽可能让每一个方法拥有一定的指责，这在debug的时候能够让你快速step-in step-out