一、结对成员 常恒 博客链接地址
二、结对互审表
|
内容 |
常恒代码（由胡昊复审） |
胡昊代码（由常恒复审） |
|
|
1.概要部分 |
1.代码是否符合需求和规格说明 |
是 |
是 |
|
2. 代码设计是否考虑周全 |
是 |
是 |
|
|
3. 代码可读性 |
代码可读性较高，思路清晰 注释全面 |
代码可读性较高 部分注释不清晰 |
|
|
4. 代码容易维护么 |
容易 |
一般 |
|
|
5. 代码的每一行都执行并检查过了吗 |
已成功通过执行并检验 |
已检查 |
|
|
2.设计规范部分 |
1.设计是否遵从已知的设计模式或项目中常用的模式 |
遵循已知的设计模式 |
已经遵循已知设计模式 |
|
2.有没有硬编码或字符串或数字等存在? |
有 |
无 |
|
|
3.代码有没有依赖于某平台，是否会影响将来的移植(如Win32到Win64)? |
否，不影响 |
否，不影响 |
|
|
4.有没有无用的代码可以清除? |
有，较少 |
存在，但无用代码不多 |
|
|
3. 代码规范部分 |
1.大小写是否区分 |
是 |
是 |
|
2.是否有相关注释 |
是 |
是，只有部分注释 |
|
|
3.是否分行 |
是 |
部分未分行 |
|
|
4.是否缩进 |
是 |
是 |
|
|
4. 具体代码部分 |
1.有没有对错误进行处理?对于调用的外部函数，是否检查了返回值或处理了异常? |
进行了处理 检查了调用函数的返回值 处理了异常 |
对错误进行了处理 检查了返回值 处理了异常 |
|
2.参数传递有无错误，字符串的长度是字节的长度还是字符(可能是单1双字节)的长度， |
无 |
无 |
|
|
3.边界条件是如何处理的? switch 语句的default分支是如何处理的?循环有没有可能出现死循环? |
根据用户输入的值作为边界 无switch语句 不能出现死循环 |
根据用户输入的值作为边界 switch语句处理正确 无死循环出现的可能 |
|
|
4.数据结构中有没有用不到的元素? |
无 |
无 |
|
|
5.效能 |
1.代码的效能如何? |
效能较好 |
效能一般 |
|
2. 代码中，特别是循环中是否有明显可优化的部分 ? |
有 |
有 |
|
|
6. 可读性 |
1.代码可读性如何?有没有足够的注释? |
可读性较高，有注释。 |
清晰易读，但注释不全面 |
|
7.可测试性 |
1.代码是否需要更新或创建新的单元测试?是否针对特定领域的开发？ |
是； 否 |
是； 否 |
三、使用 常恒 的代码进行结对编程
（a）需共同遵循的编程规范
1.变量命名：尽量使用见名知意的名字，尽量不使用拼音作为变量名。若需要两个及以上单词命名，第二个单词开始，首字母大写。
2.注释规范：变量功能、方法功能必须要进行注释。
3.缩进规范：每行最多一条语句。
（b）结对编程感受
通过结对编程，两人互相评审了对方的代码，通过对方对自己的评审，使自己了解到自己编程时的不规范之处。选取其中一人的代码进行重新编写，二人制定共同的编程规范，使得程序的可读性大大提高，两人都能看懂对方书写的代码部分。同时，两人共同完成同一个程序，对功能的实现进行了有效的沟通，此过程中，二人发表自己独特的想法，使得功能的实现出现了多种可能性。这样的结对编程，不仅能开发出高质量的程序，也能增进两个人的交流、沟通能力，增强对彼此的了解，同时认识到合作的重要性。
（c）结对编程过程
四、项目编程要求
新增功能：
1、增加对输入数据的异常处理，处理输入数据不符合输入要求的情况
2、将功能分类，不同的功能写在不同的类中
3、增大算式生成数的范围（如整数存不下的数），程序如何处理。
程序地址：
https://github.com/users/changheng-gt3/projects/1