第七周作业

代码复审

注：本文部分链接引用了项目中的私有文件，仅供小组成员及任课教师登陆coding后查看，如有不便请谅解。

《构建之法》上对代码复审的定义是：看代码是否在“代码规范”的框架内正确地解决了问题。代码复审可以检查大家对代码规范的执行情况，发现代码中的一些问题，提高代码的质量，所以我们安排了小组成员互相进行代码复审。

复审前

代码复审需要检查对代码规范的执行情况，所以我们先要有明确的代码规范。代码规范其实应当在代码编写前就确定下来，但是我们因为一些原因直到复审开始前才制定出用于本组的代码规范，这也导致了我们进行代码复审时发现的问题比较多。我们小组使用的语言是微软公司的C#，微软官方有相应的文档，但是不够详细。而对于coding平台提供的自动检查功能，我又找不到其所使用的规范的具体内容，故无法采用。最后我在网上查找了其它文档，参考了这篇文章，制定了本小组的代码规范。

而小组的其他成员对这份规范的第一反应是：看不懂。的确，我们刚刚接触C#，规范中提到的许多语法特性我们并不知道，也没有在项目中使用。而一些设计方面的东西，由于我们的项目规模不大，我们也没有涉及这方面的内容。这份应该是来自企业的文档，在我们看来是又长又难懂。经过讨论，我们决定结合本小组的实际情况，只对这份规范的一部分进行复审，并且委托小组成员根据规范内容做出了一份简单明了的复审表格，供复审时对照。

复审中

我负责进行复审的代码是PlayerControl类中他人编写的部分。根据代码规范，我作出了相应的复审报告。这份代码的问题主要违反了以下两点：

每行代码和注释不要超过70个字符或屏幕的宽度,超过则应换行,换行后的代码应该缩进一个Tab.
除了 for 循环外,声明要放在块的最开始部分.

对于第一点，代码编写者的反馈是对应的代码并没有超出他电脑上的屏幕宽度，然而在我的电脑上是没法在一行显示的。这体现了我们选择的代码规范本身有不严谨的地方，屏幕宽度并没有具体的量化标准。我们讨论后觉得这个问题也不是特别严重，所以没有修改规范的内容，只是相互沟通处理。

对于第二点，规范上的这条规定跟我们平常的习惯并不符合。变量声明集中在开头的确显得整齐，然而拉长了代码的长度，声明与使用的距离比较远，编写的时候并不方便。而在使用时声明则更符合思维习惯，可以对变量按照方法内的功能逻辑部分进行集中。代码规范也有着方便小组成员交流的目的，我们在这方面的习惯比较一致，觉得没有必要改变，而且Unity官方的示例也没有将声明集中在开头。所以经过讨论，我们决定从代码规范中删除这一项内容。

复审后

第一轮复审后，我们根据复审报告对代码进行修改，直到完全符合代码规范。

经过这次代码复审的实战，我有了一些新的体会。以前编写代码几乎就是自己一个人写给自己看，写完之后如果表现得正常甚至自己都不会看第二遍。而在团队中，我们要遵循同样的规范，不能随心所欲，要考虑到其他人也能看懂，所以变量名也变得讲究，注释也写得多起来了，这样团队成员才能更好地沟通。复审时对同伴逐行地解释自己所写的代码，自己的确也发现了编码时没注意到的问题，这对与提升代码的质量很有帮助。