实验四 代码评审
一、实验目的
1） 了解代码审查的含义；
2） 掌握相关编程规范检查工具的安装与使用；
二、实验内容及要求
Code Review中文应该译作“代码审查”或是“代码评审”或“代码复查”，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。Code Review主要用来在软件工程过程中改进代码质量，通过代码评审可以达到如下目的：
●在项目早期就能够发现代码中的BUG
●帮助初级开发人员学习高级开发人员的经验，达到知识共享
●避免开发人员犯一些很常见，很普通的错误
●保证项目组人员的良好沟通
●项目或产品的代码更容易维护
代码评审主要内容是编程规范，重构方法，架构设计，性能安全，日志，可读性，扩展性等问题。通过代码评审可查找和修复引入到开发阶段的应用程序的错误，提高软件的整体素质和开发者的技能。代码评审的作用和意义已在很多技术团队内达成共识，可是很多时候并未被有效执行，甚至被认为是一项费时费力的工作。借助一些工具可以更容易，更有效率地来进行Code Review。
1、以小组形式，针对前面“实验一”中所完成的代码，进行代码评审(走查)，重点检查以下情况。你也可有查询相关材料，建立更细化的检查清单（check list）
-
程序是否能正常工作，代码是否实现预期的功能，逻辑是否正确。
-
代码是否遵循的编程规范
-
代码是否尽可能的模块化
-
所有的数据输入是否都进行了检查
-
是否有注释，并且描述了代码的意图
-
代码的可理解性和可测试性
2、按“实验二”的分组方式，两人一组，随机分配另一组的代码作为本组评审和分析的对象
一些编码规范的检查工具如下，也可自行查找工具使用。
三、实验过程
（1）配置代码审查工具。要求采用屏幕截图的方式配置的过程；
（2）使用工具对原始代码进行评审和分析，记录结果，期间不要有任何修改；
（3）对工具执行结果进行人工分析，结合检查清单和人工走查的出代码修改建议；
（4）通过github issues向项目维护者提交问题(issue),注意一个issue 只报告一个问题，多个问题需放在多个issue中，以便跟踪。
（5）记录总结实验过程中遇到的问题和解决过程
四、实验记录
1.审查准备
(1)所审查为java代码，安装eclipse的checkstyle插件：Help-->Eclipse Marketplace，搜索checkstyle，进行install。重启。
(2)clone代码到本地。(https://github.com/wbr1224/LifeGame)
2.运行测试
运行结果与代码功能相符。
3.代码规范
经过插件审查后，主要有以下几种不规范处：
(1)缩进，空格，换行以及省略{}
大多数的缩进，空格换行规范我认为是不同人的习惯，并没有影响代码的可读性，除非有的规范文件要求，不然我认为可以忽略。
其中有几处if/else的{}省略，我认为会影响可读性，需要注意。
(2)包的导入
该代码中导入包类时用了*，在规范下，应尽量用什么，写什么。其中有一种包引用顺序的规范提示，其依据是import语句在实际从磁盘上加载模块之前，会先去检查这个字典，未按默认顺序导入，会提示。而在以后的公司规范中，有可能对内部库，外部库的导入顺序有要求，应该注意。
(3)javadoc
javadoc的错误第一次见，在查阅资料后：
javadoc是Sun公司提供的一个技术，它从程序源代码中抽取类、方法、成员等注释形成一个和源代码配套的API帮助文档。也就是说，只要在编写程序时以一套特定的标签作注释，在程序编写完成后，通过Javadoc就可以同时形成程序的开发文档了。
一些注释的错误格式，或缺失会提示该错
(4)JLS建议的修饰符顺序
static修饰符的顺序不符合JLS的建议，默认的顺序是 public,protected,private,abstract,static,final,transient,volatile,synchronized,native,strictfp。
(5)tab解决
这种问题应该都有，没有关系。为了避免Tab键在代码中出现，我们可以把Tab键设置为4个空格解决。在实际中借助博客(https://blog.csdn.net/q316510202/article/details/50777942)进行解决。
4.问题提交
尽量一个issue一个问题提交，有利于追踪反馈。以下是我和伙伴就问题进行的几次反馈。
五.实验小结
只有借助规范软件的帮助，才能发现一个不报错的代码，还有多少不规范的地方。每一个不规范的地方，都有可能影响代码的可读性与兼容性，有的甚至可以进一步的优化运行的速度。因此规范化的代码是必不可少的。以下是转载博客(https://www.cnblogs.com/pangxiansheng/p/5239655.html)的相关规范提示。
