第四次作业
1.在学习通上注明结对的成员对:4班李运鹏-4班苏世超
2.结对成员的博客链接地址
李运鹏:https://www.cnblogs.com/liyunpeng123/
苏世超:https://www.cnblogs.com/1-1111/
3.结对成员对四则运算项目进行代码互审，并给出代码审查结果表
a:李运鹏的代码审查表（由苏世超完成）
|
代码复审检查表 |
||
|
概要部分 |
代码符合需求和规格说明么？ |
符合 |
|
代码设计是否考虑周全？ |
否 |
|
|
代码可读性如何？ |
一般 |
|
|
有冗余的或重复的代码吗? |
无 |
|
|
代码的每一行都执行并检查过了吗？ |
是 |
|
|
设计规范部分 |
设计是否遵从已知的设计模式或项目中常用的模式？ |
是 |
|
有没有硬编码或字符串存在？ |
有 |
|
|
代码有没有依赖于某一平台？ |
无 |
|
|
有没有无用的代码可以清除？ |
无 |
|
|
代码规范部分
|
修改的部分符合代码标准么? |
是 |
|
修改的部分符合代码风格么? |
是 |
|
|
具体代码部分 |
数据结构中有没有用不到的元素？ |
无 |
|
对于调用的外部函数，是否检查了返回值？ |
是 |
|
|
效能 |
代码的效能如何？ |
一般 |
|
循环中是否有明显可优化的部分？ |
没有 |
|
|
可读性 |
代码可读性如何？有没有足够的注释？
|
可读性较好，没有注释 |
|
可测试性 |
是否需要更新或创建新的单元测试？ |
否 |
b:苏世超的代码审查表（由李运鹏完成）
|
代码复审检查表 |
||
|
概要部分 |
代码符合需求和规格说明么？ |
符合 |
|
代码设计是否考虑周全？ |
否 |
|
|
代码可读性如何？ |
一般 |
|
|
有冗余的或重复的代码吗? |
无 |
|
|
代码的每一行都执行并检查过了吗？ |
是 |
|
|
设计规范部分 |
设计是否遵从已知的设计模式或项目中常用的模式？ |
是 |
|
有没有硬编码或字符串存在？ |
有 |
|
|
代码有没有依赖于某一平台？ |
无 |
|
|
有没有无用的代码可以清除？ |
无 |
|
|
代码规范部分
|
修改的部分符合代码标准么? |
是 |
|
修改的部分符合代码风格么? |
是 |
|
|
具体代码部分 |
数据结构中有没有用不到的元素？ |
无 |
|
对于调用的外部函数，是否检查了返回值？ |
是 |
|
|
效能 |
代码的效能如何？ |
一般 |
|
循环中是否有明显可优化的部分？ |
没有 |
|
|
可读性 |
代码可读性如何？有没有足够的注释？
|
可读性较好，没有注释 |
|
可测试性 |
是否需要更新或创建新的单元测试？ |
否 |
4.代码编写基本规范
第一点：源代码文件以文件内容中的最顶层的Java类命名，而且大小写敏感，文件扩展名为 .java，同时，文件的编码格式统一为UTF-8。
第二点：类的命名遵循大驼峰命名法UpperCamelCase，而方法名和变量名的命名遵循小驼峰命名法lowerCamelCase。常量名使用大写字母表示，单词之间以下划线分隔.jsp的文件名全部小写。
第三点：一个程序文件最好不要超过2000行。
第四点：不用的代码和引用删除.
第五点：请合理运用空行。空行可以用来隔开相对独立的代码块，有利于阅读和理解。但是不要使用超过一行的空行，对空间，别太奢侈了。
第六点：为不容易理解类变量注释。注释代码段，注释逻辑选择。
第七点：对成员方法,不要轻易采用public的成员变量。主要的修饰符有public, private, protected。避免过多的参数列表，尽量控制在５个以内。
第八点：原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。另每一行的长度不应超过屏幕太多，必要时适当换行，换行时尽可能在","处或运算符处，换行后最好以运算符打头。
第九点：为避免编程时遇到麻烦，请保证在自己类路径指到的任何地方，每个名字都仅对应一个类。否则，编译器可能先找到同名的另一个类，并报告出错消息。
第十点：字符串不应该重复，如果多次用到同一字符串，建议将该字符串定义为字符串常量，再引用。
5.结对场景照片
6.结对编程的感受
李运鹏：这两天进行了一些结对编程的训练，其实在之前的一些大作业的过程中也进行过类似结对编程工作，但是没有像这次一样分工明确，相比来说，这次的效率要更高些。与一个人编程相比较，结对编程有很多优点。比如我自己写代码时不太注意编程规范，所以代码风格不是很优秀，再次读自己写的代码时就像看天书一样，可读性很差，但是两人结对编程的话两人可以互相商量变量命名等事宜，一个人也可以提醒代码规范的问题。结对编程时还能减少bug，“驾驶员”长期盯着屏幕，很容易疲劳而犯一些小错误，这时“领航员”便可轻松的指出错误以减少bug的产生，同样的，调试bug的速度也变快了。总之结对编程虽然降低了一些效率，但是写出的代码错误率更低，代码质量更高，也未尝不是一种补偿。但是结对编程并不是适合所有人，有的人就是喜欢一个人编程，两人结对编程的效率一部分取决于两个程序员的熟悉程度，所以两个人刚开始结对编程时需要一段时间来适应。
苏世超：俗话说”三个臭皮匠，胜过一个诸葛亮”，大家在做同一件事时，集思广义发挥各自优点，可以使我分析更能切中要害。比如在设计阶段，我们其中一个人想到采用策略模式来解决这个问题，采用一个接口作为抽象行为层。另外一个人发现我们这些具体的算法类有一些公用行为，于是考虑用抽象类代替原来的接口作为抽象行为层，这样可以把那些公用行为上移到抽象层，大大减少了冗余代码，使设计变得更加优雅。相互督促可以使我们都能集中精力，更加认真的工作，我们对业务的理解深度相差无几，设计在我们共同讨论中产生。比如我们其中一个人，按照我们共同完成的活动图去编程，完成一小段逻辑后，另外一个人会马上给出意见，说出代码存在的潜在问题，这个潜在的问题，很可能是因为我们当时对业务理解存在偏差造成的。很可能这个时候我们要对设计进行改动以适应业务。如果是一个人在编程，恐怕很难找到这样的问题。任何一段代码都至少被两双眼睛看过，两个脑袋思考过，代码的质量会得到有效提高。“三人行必有我师”，相互学习对方的技能，可以提升自己水平。
7.github的链接地址
