| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/2018CST/ |
| 这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/14604444.html |
| 我的课程学习目标 | （1）体验软件项目开发中的两人合作，练习结对编程。（2）掌握Github协作开发程序的操作方法。 |
| 这个作业在哪些方面帮助我实现学习目标 | 两人合作练习结对编程、掌握Github协作开发程序的操作方法以及运用学习工具 |
| 结对方学号-姓名 | 201871010113 刘兴瑞 |
| 结对方本次博客作业链接 | https://www.cnblogs.com/lxr0/ |
| 本项目Github的仓库链接地址 |
一、实验内容和步骤
任务1：
阅读《现代软件工程—构建之法》第3-4章内容，理解并掌握代码风格规范、代码设计规范、代码复审、结对编程概念；
完成情况：
已认真阅读现代软件工程—构建之法》第3-4章内容，个人认为的一些重要概念如下。
（1）代码风格的原则是：简明，易读，无二义性。具体从缩进、行宽、括号、断行与空白的{ }行、分行、命名、下划线问题、大小写问题、注释等九个大的方面具体设置了代码风格的规范。
1）缩进：4个空格，不用Tab键是因为在不同的情况下显示的长度可能不一样。
2）行宽：限定为100字符。
3）括号：在复杂的条件表达式中，可以清晰地表示逻辑优先级。
4）断行与空白的{}行：断行在程序调试时可以清晰的表达变量的变化情况，{}来判断程序的结构。
5）分行：不要把多个变量定义在一行上。
6）命名：
①在变量名中不要提到类型或其他语法方面的描述。
②避免过多的描述。
③如果信息可以从上下文中得到，那么此类信息就不必写在变量名中。
④避免可要可不要的修饰词。
7）下划线：用来分割变量名字中的作用域标注和变量的语义。
8）大小写：
①所有类型/类/函数名都用Pascal形式（所有单词第一个字母都大写）。
②所有变量都用Camel形式（第一个单词全部小写，随后单词用Pascal形式）。
③类/类型/变量：名词或组合名词。
④函数则用动词或动宾组合词来表示。
9）注释：注释是为了解释程序做什么（What），为什么这样做（Why）以及要特别注意的地方。
（2）代码设计规范不光是程序书写的格式问题，而且牵涉到程序设计、模块之间的关系、设计模式等方方面面，这里有不少与具体程序设计语言息息相关的内容（如C、C++、Java、C#），但是也有通用的原则，这里主要讨论通用的原则，主要从以下四个大的方面展开：函数、goto、错误处理、如何处理C++中的类。
1）函数：原则：只做一件事，并且要做好。
2）goto:函数最好有单一出口，为了达到这一目的，可以使用goto。
3）错误处理：
①参数处理：在Debug版本中，所有的参数都要验证其正确性，在正式版本中，对从外部（用户或别的模块）传递过来的参数，要验证其正确性。
②断言：验证正确性就要用断言。
4）如何处理C++中的类
①类：
a.使用类来封装面向对象的概念和多态。
b.避免传递类型实体的值，应该用指针传递。换句话说，对于简单的数据类型，没有必要要用类来实现。
c.对于有显示的构造和析构的类，不要建立全局的实体，因为不知道它们在何时创建和消除。
d.仅在有必要时，才是用“类”。
②class vs.struct：如果只是数据的封装，用struct即可。
③公共/保护/私有成员：按照这样的次序来说明类中的成员。
④数据成员：
a.数据类型的成员用m_name说明。
b.不要使用公共的数据成员，要用inline访问函数，这样可兼顾封装和效率。
⑤虚函数
a.使用虚函数来实现多态。
b.仅在很有必要时，才使用虚函数。
c.如果一个类型要实现多态，在基类中的析构函数应该是虚函数。
⑥构造函数
a.不要在构造函数中做复杂的操作，简单初始化所有成员即可。
b.构造函数不应该返回错误。
⑦析构函数
a.把所有的清理工作都放在析构函数中。如果有些析构函数在之前就释放了，要重置这些成员为0或NULL。
b.析构函数也不应该出错。
⑧new和delete
a.如果可能，实现自己的new/delete，这样可以方便地加上自己的跟踪和管理机制。自己的new/delete可以包装系统提供的new/delete。
b.检查new的返回值。new不一定都成功。
c.释放指针时不用检查NULL。
⑨运算符
a.在理想情况下，我们定义的类不需要自定义操作符。确有必要时，才会自定义操作符。
b.运算符不要做标准语义之外的任何动作。
c.运算符的实现必须非常有效率，如果有复杂的操作，应定义一个单独的函数。
d.当拿不定注意时，用成员函数，不要用运算符。
⑩异常
a.不要用异常作为逻辑控制来处理程序的主要流程。
b.当使用异常时，要注意在什么地方清理数据。
c.异常不能跨过DLL或进程的边界来传递消息，所以异常不是万能的。
⑪类型继承
a.仅在有必要时，才使用类型继承。
b.用const标注只读的参数。
c.用const标注不改变数据的函数。
（3）代码复审的正确定义：看代码是否在“代码规范”的框架内正确地解决了问题。
复审的目的在于：
1）找出代码的错误。如：
2）发现逻辑错误，程序可以编译通过，但是代码的逻辑是错的。
3）发现算法错误，比如使用的算法不够优化。
4）发现潜在的错误和回归性错误——当前的修改导致以前修复的缺陷又重新出现。
5）发现可能改进的地方。
6）教育（互相教育）开发人员，传授经验，让更多的成员熟悉项目各部分的代码，同时熟悉和应用领域相关的实际知识。
复审的形式：
（4）结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。
结对编程中有两个角色：
1）驾驶员（Driver）是控制键盘输入的人。
2）领航员（Navigator）起到领航、提醒的作用。
任务2：
两两自由结对，对结对方《实验二 软件工程个人项目》的项目成果进行评价，具体要求如下：
对项目博文作业进行阅读并进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，将以上评论内容发布到博客评论区。
结对伙伴：201871010113-刘兴瑞
结对方博客链接：https://www.cnblogs.com/lxr0/
评论链接：https://www.cnblogs.com/lxr0/p/14599331.html
克隆结对方项目源码到本地机器，阅读并测试运行代码，参照《现代软件工程—构建之法》4.4.3节核查表复审同伴项目代码并记录。
1、概要部分
（1）代码符合需求和规格说明么？
答：部分符合需求与规格。
（2）代码设计是否有周全考虑？
答：基本周全，改动的地方很少。
（3）代码可读性如何？
答：可读性好。
（4）代码容易维护么？
答：较易。
（5）代码的每一行都执行并检查过了吗？
答：是的，检查过。
2、设计规范部分
（1）设计是否遵从已知的设计模式或项目中常用的模式？
答：部分遵从。
（2）有没有硬编码或字符串/数字等存在？
答：有一部分。
（3）代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到Win64）
答：没有依赖，不会影响移植。
（4）开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？
答：可以实现，存在，调用了一部分。
（5）有没有无用的代码可以清除？（很多人想保留尽可能多的代码，因为以后可能会用上，这样导致程序文件中有很多注释掉的代码，这些代码都可以删除，因为源代码控制已经保存了原来的老代码。）
答：有，基本清除完毕。
3、代码规范部分
（1）修改的部分符合代码标准和风格么（详细条文略）?
答：大部分代码符合，不符合的已修改。
4、具体代码部分
（1）有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？
答：对错误进行了处理，检查了返回值，并处理了异常。
（2）参数传递有无错误，字符串的长度是字节的长度还是字符（可能是单/双字节）的长度，是以0开始计数还是以1开始计数？
答：无错误，字符串的长度是字节的长度，是以0开始计数。
（3）边界条件是如何处理的？Switch语句的Default是如何处理的？循环有没有可能出现死循环？
答：结对伙伴未用到Switch语句，没有出现死循环，循环语句正确。
（4）有没有使用断言（Assert）来保证我们认为不变的条件真的满足？
答：没有使用。
（5）对资源的利用，是在哪里申请，在哪里释放的？有没有可能导致资源泄露（内存、文件、各种GUI资源、数据库访问的连接，等等）？有没有可能优化？
答：是随机生成的，不会导致资源泄漏，有可能优化。
（6）数据结构中是否有无用的元素？
答：没有。
5、效能
（1）代码的效能（Performance）如何？最坏的情况是怎样的？
答：代码正确，程序运行正常。
（2）代码中，特别是循环中是否有明显可优化的部分（C++中反复创建类，C#中 string 的操作是否能用StringBuilder 来优化）？
答：没有可优化地方，比较优化。
（3）对于系统和网络调用是否会超时？如何处理?
答：不会超时。
6、可读性
代码可读性如何？有没有足够的注释？
答：代码不是很复杂，有足够的注释。
7、可测试性
代码是否需要更新或创建新的单元测试？还可以有针对特定领域开发（如数据库、网页、多线程等）的核查表。
答：不需要。
任务3：采用两人结对编程方式，设计开发一款D{0-1}KP 实例数据集算法实验平台，使之具有以下功能：
（1）平台基础功能：实验二 任务3；
（2）D{0-1}KP 实例数据集需存储在数据库；
（3）平台可动态嵌入任何一个有效的D{0-1}KP 实例求解算法，并保存算法实验日志数据；
（4）人机交互界面要求为GUI界面（WEB页面、APP页面都可）；
（5）查阅资料，设计遗传算法求解D{0-1}KP，并利用此算法测试要求（3）；
（6）附加功能：除（1）-（5）外的任意有效平台功能实现。
1、需求分析陈述。
实例数据集需存储在数据库;
平台可动态嵌入任何一个有效的D{0-1}KP 实例求解算法，并保存算法实验日志数据；
2、软件设计说明。
3、描述结对的过程，提供两人在讨论、细化和编程时的结对照片(非摆拍)。
4、提供此次结对作业的PSP。
| PSP2.1 | 任务内容 | 计划共完成需要的时间(min) | 实际完成需要的时间(min) |
|---|---|---|---|
| Planning | 计划 | 15 | 15 |
| ·Estimate | 估计这个任务需要多少时间，并规划大致工作步骤 | 15 | 15 |
| Development | 开发 | 1500 | 2050 |
| Analysis | 需求分析 (包括学习新技术) | 30 | 60 |
| Design Spec | 生成设计文档 | 15 | 20 |
| Design Review | 设计复审 (和同事审核设计文档) | 20 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 15 |
| Design | 具体设计 | 500 | 600 |
| Coding | 具体编码 | 1000 | 800 |
| Code Review | 代码复审 | 180 | 180 |
| Test | 测试（自我测试，修改代码，提交修改） | 150 | 120 |
| Reporting | 报告 | 75 | 100 |
| Test Report | 测试报告 | 80 | 90 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结 ,并提出过程改进计划 | 15 | 25 |
5、小结感受：两人合作真的能够带来1+1>2的效果吗？通过这次结对合作，请谈谈你的感受和体会。
我感觉两个人合作的效率还是比较高的，在合作的过程中，结对的伙伴之间可以相互学习，共同进步。在问题的解决上可以，不同的人会有不同的方法，结对编程时可以两个人交流，互相学习，最终会找到一个行之有效的高效解决方案。在项目完成方面，结对编程还是会带来1+1>2的效果。而且两个人可以互换角色，更好的改进程序，此外自己编写程序时，有些错误自己发现不了，在结对编程时，同伴可以帮你更好的处理这些问题。但是每个人的性格，做事方式还是会有一定的差异，在结对编程的过程中，需要通过正确的方法来沟通，以保证团队工作的顺利进行。