Lab5

3.1 Static Program Analysis

针对 Lab4 中提交的最新版本代码，进行静态代码分析。

3.1.1 人工代码走查（walk through）

列出你所发现的问题和所做的修改。每种类型的问题只需列出一个示例即可。

之前写条件判断if和else时，如果只有一条语句，没有加花括号，例如：

checkRep、构造方法和main方法没有写javadoc，有点想当然了。

对于泛型类的equals重写：一开始注明了具体的泛型类，会产生unchecked cast的warning。修改如下：

3.1.2 使用CheckStyle和SpotBugs进行静态代码分析

列出你所发现的问题和所做的修改。每种类型的问题只需列出一个示例即可。
对比分析两种工具发现问题的能力和发现问题的类型上有何差异。

CheckStyle很好地发现了不符合google规范的代码(人工走查时没有发现)，例如将多个变量定义在一起：

SpotBugs找出代码逻辑上存在的bug，例如我在使用bufferedreader的readline方法时没有考虑读入为空的情况：

SpotBugs会给出对于该bug的可能性(目前只见过high confidence和normal confidence)

两种工具都是旨在找出代码中的问题，不同之处在于：CheckStyle关注的是代码的结构问题，不修改不会影响程序的运行，但会降低代码的可读性；而SpotBugs旨在找出代码中的漏洞，不修改可能会引起程序的崩溃。

3.2 Java I/O Optimization

3.2.1 新功能：持久化存储

首先在TrackGame添加方法save，然后在客户端Main.java中增加一个功能：将当前的circularOrbit修改过后存入新的文件client.output中。目录结构如下：

3.2.2 多种I/O实现方式

实现了哪些I/O方式来读写文件，具体如何实现的。

读文件采用的三种分别是BufferedReader、FileInputStream和Scanner；写文件采用的三种分别是BufferedWriter、FileOutputStream和FileWriter。具体时间大体相同，目录结构如下：

如何用strategy设计模式实现在多种I/O策略之间的切换。

为三种策略定义相同的interface，在具体应用中的readFileAndBuild方法中添加了一个参数InputStrategy，根据不同的参数切换不同的策略(同理OutputStrategy)。
p.s. 在三个具体应用中分别使用了三种不同的InputStrategy和OutputStrategy以证明其正确性。

3.2.3 多种I/O实现方式的效率对比分析

采用的测试文件为老师提供的50万行左右的TrackGame.txt和90万行左右的SocialNetworkCircle.txt。为了测试方便没有在客户端Main中测试，而是编写了两个测试文件：TrackGameTest和SocialNetworkCircleTest。刚开始设计时没有新建轨道系统对象，只是根据几个Strategy单纯测量了一下IO时间；后来又按行读入解析文件，因此读文件的时间变成了读取文件+构造系统的时间。

如何收集你的程序I/O语法文件的时间。

在调用readFileAndBuild和save方法前后通过system.currentTimeMillis方法获取时间并作差值，得到IO所消耗的时间。

表格方式对比不同I/O的性能。

图形对比不同I/O的性能。
纯IO：

通过轨道系统对象测量的IO：