结对成员博客链接
马进 -> https://www.cnblogs.com/jinma/p/11729160.html
代码审查结果表
| 内容 | 蒲文强代码（由马进复审） | 蒲文强代码（由马进复审） | |
|---|---|---|---|
| 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.代码是否需要更新或创建新的单元测试?是否针对特定领域的开发？ | 是； 否 | 是； 否 |
代码编写基本规范
1. 关键字public，protected，private不要缩进，声明的函数和变量缩进一个制表符
2. 类声明前应该加上注释，注明该类的作用
3. 类中成员必须进行初始化，可以通过构造函数的初始化列表初始化成员的函数。
4. 在每个类声明之后，每个函数定义结束之后都要加一个空行。
5. 一行代码只做一个事情，这样代码易于阅读。
6. 代码的最大长度宜控制在70-80个字节。
7. 标识符应当直观且可以拼读，做到见名知意。
8. 字符串不应该重复，如果多次用到同一字符串，建议将该字符串定义为字符串常量，再引用。
9. 为不容易理解类变量注释。注释代码段，注释逻辑选择。
结对编程的感受
通过此次结对编程，我最大的感受就是体会到了团队协作的重要性，在开发层次上，结对编程能提供很好的设计质量和代码质量，两人合作能有更强的解决问题的能力，对于开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感，同时能够降低学习成本，一边编程，一边共享学习知识和经验。结对编程的过程收获颇多，我觉得结对编程有好有坏，但是好处远远大于的不好的地方。两个人难免会遇到意见不同的时候，关键是看此时如何协调、如何沟通、如何采纳。如果团队内部很好地处理这些分歧，那么非但不能提高效率，反而会拖慢工作的进程。如果团队协调得很好，那么两个人的力量是绝对大过一个人的。
结对场景图片
结对项目编程要求
增加的需求：增大算式生成数的范围（如整数存不下的数），程序如何处理。