实验四 代码评审
一、实验目的
1） 了解代码审查的含义；
2） 掌握相关编程规范检查工具的安装与使用；
二、实验内容及要求
1、以小组形式，针对前面“实验一”中所完成的代码，进行代码评审(走查)，重点检查以下情况。你也可有查询相关材料，建立更细化的检查清单（check list）
- 程序是否能正常工作，代码是否实现预期的功能，逻辑是否正确。
- 代码是否遵循的编程规范
- 代码是否尽可能的模块化
- 所有的数据输入是否都进行了检查
- 是否有注释，并且描述了代码的意图
- 代码的可理解性和可测试性
2、按“实验二”的分组方式，两人一组，随机分配另一组的代码作为本组评审和分析的对象
一些编码规范的检查工具如下，也可自行查找工具使用。
java语言 :采用使用eclipse Checkstyle插件 ;
- CheckStyle是SourceForge下的一个项目，提供了一个帮助JAVA开发人员遵守某些编码规范的工具。它能够自动化代码规范检查过程，从而使得开发人员从这项重要但枯燥的任务中解脱出来。它可以根据设置好的编码规则来检查代码。比如符合规范的变量命名，方法体的最大行数，重复代码检查等等。
如果你使用idea ，可以使用Alibaba Java Code Guidelines插件，参考链接如下：https://github.com/alibaba/p3c/wiki/IDEA%E6%8F%92%E4%BB%B6%E4%BD%BF%E7%94%A8%E6%96%87%E6%A1%A3
C++语言:可使用Google代码规范工具Cpplint;
- Cpplint是一个python脚本，Google使用它作为自己的C++代码规范检查工具，VSCcode可配置Cpplint对C++代码进行规范检查。
python:可采用pylint;
- Pylint 是一个 Python 代码分析工具，它分析 Python 代码中的错误，查找不符合代码风格标准（Pylint 默认使用的代码风格是 PEP 8，具体信息，请参阅参考资料）和有潜在问题的代码。目前在 eclipse 的 pydev 插件中也集成了 Pylint，VSCcode可安装pylint插件
当发现了项目存在的问题后，可通过Bug跟踪系统向项目维护者反馈问题（issue）,管理Issue的系统称为BTS（Bug Tracking System，Bug跟踪系统）。当今具有代表性的BTS有Redmine、Trac、BugZilla等。GitHub自身也加入了BTS的功能。在GitHub上，可以将它作为软件开发者之间的交流工具。通过github的issues功能开发者可以便捷的发现软件的BUG并报告，想向项目所有人询问或用来追踪各种想法探讨准备实施的任务。
三、实验过程
1、 配置代码审查工具。要求采用屏幕截图的方式配置的过程；
在GitHub中进入我审查的项目仓库。查看仓库地址，在git 中输入命令git clone https://github.com/end57/my-nihotel-plans.git,将该项目克隆到自己的文件中。通过查看项目信息，发现该工程使用的是JAVA语言，所以我选择使用eclipse Checkstyle插件进行代码评审 。
在网上搜索了如何安装插件，参考链接：https://blog.csdn.net/clk_esunny/article/details/80248636
（1）点击“help”—>选择“Install New Software…”，弹出Install框，在Install框里，点击“Add”按钮，弹出“Add Repository”框，输入框输入所要安装插件的名称CheckStyle和链接地址http://sourceforge.net/projects/eclipse-cs/files/updatesite/5.6.0/，再点击Add按钮。
(2)勾选所要安装的插件，点击“Next”按钮，再点击“Next”按钮,选择“I accept the terms of …”，点击“Finish”按钮,有时会弹出一个安全警告框，直接点击“OK”按钮即可最后提示需要restart（重启），点击“Yes”按钮重启之后这个插件就被安装了。
（3）点击“Window”—>选择“preferences”，弹出preferences框，在里面我们可以看到Checkstyle，这表示插件已经安装成功。
（4）在空白处任意地方单击右键，可以看到菜单中多了CheckStyle的选项，这个就是我们刚才安装的插件。
安装完CheckStyle之后，检查代码时默认的检测规则其实和我们目前的规则有一些差异，我们需要添加项目的统一规则文件。
（1）首先从网上下载项目同一的规则文件。
（2）打开eclipse，在window选项中找到Preferences，点击打开的窗口中也会多出来一个CheckStyle，点击New，把规则文件加进去。输入Name和Location,设置为默认规则，然后点击OK
（3）点击“OK”之后会发现右侧的列表中多了一个规则文件，就是我们新添加的，然后选中新加的那行，在最右侧按钮区域点击Set as Default，这就说明自己配置的规则文件已经正式启用了。
（4）效果显示:选中工程，单击右键，选择checkstyle ——>Check Code with Checkstyle 进行代码审查。出现错误的代码背景为粉色，左边有一个放大镜鼠标放到错误信息上会提示错误原因。
2、使用工具对原始代码进行评审和分析，记录结果，期间不要有任何修改；
（1）利用Checkstyle插件，进行代码审查。以下是例出来的一部分错误：
①出现了多于的大括号 ②出现了魔法数，即数据标识常量化
③类的命名规则 ④if语句少了大括号
3、对工具执行结果进行人工分析，结合检查清单和人工走查的出代码修改建议；
根据代码审查的结果，进行统计，出现的问题如下图所示：
4、通过github issues向项目维护者提交问题(issue),注意一个issue 只报告一个问题，多个问题需放在多个issue中，以便跟踪。
通过跟小组成员讨论，我们决定提交一下6个比较更加注意的问题：
5、记录总结实验过程中遇到的问题和解决过程
（1）问题：刚开始根据老师学习通里面的安装CheckStyle的步骤进行安装，直接填了课件上的连接地址，不需要自己命名，安装好后出现的是阿里集团编码规约，在执行评审时，没有出现预期的结果，于是便自己在网上搜索了安装该插件的步骤，安装好后执行，还是同样的结果，后来发现是我所建的项目工程的问题；
解决：将自己所建立的工程和复制的需要被评审的代码的包删除，直接用eclipse导入需要被评审的工程，再次执行评审命令时，问题解决。
（2）问题：在添加自己从网上找到的的规则文件时，总是报错，无法添加
解决：在网上搜索了相关问题的原因，是因为输出有中文，我尝试这改了改了一下，但是问题没有解决，于是把带有中文的有效值删除之后，文件就添加进去了。
（3）问题：由于导入的规则文件在评审代码时提示的是英文，给我记录错误带来了很大的不便，而且问题整理的比较乱；
解决：我又安装了老师学习通里所介绍的插件安装，此方法安装过程，评审结果都很简便易懂，我和小组成员根据两种插件所评审的结果进行了分析和综合，大致解决了英文提示所带来的困扰。
实验小结
通过这次实验，才知道自己写的代码原来是那么的不规范，一直以为运行不报错，缩进正确就是规范的代码，这是很大的误区。在这次实验过程中也遇到了很多的问题，安装插件的不顺利，安装上插件之后使用不了等等，不过最后通过百度和多次尝试之后问题也基本都解决了，但是很有很多不足的地方，比如问题整理的比较乱等。但是收获也很多，代码评审有很多方法，要多尝试，体验不同插件的不同审查过程。
