| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | 18级卓越班 |
| 这个作业要求链接 | 实验三 软件工程结对项目 |
| 我的课程学习目标 | 1.熟悉PSP流程 2. 熟悉github操作 3.加深对D{0-1}问题的解法的理解 4.熟悉java语言开发程序的一般流程 5.体验软件项目开发中的两人合作，练习结对编程 |
| 这个作业在哪些方面帮助我实现学习目标 | 1. 更加熟练git的相关操作 2. 熟练markdown编辑器的使用方法 3.温习使用前后端分离技术开发网站的过程 4.学会GitHub协作开发的操作 |
| 结对方学号-姓名 | 201871030116-李小龙 |
| 结对方本次博客作业链接 | 实验三 软件工程结对项目 |
| 本项目Github的仓库链接地址 | 仓库地址 |
任务1：阅读《现代软件工程—构建之法》第3-4章内容，理解并掌握代码风格规范、代码设计规范、代码复审、结对编程概念；
1、代码风格规范
（1）代码风格的原则是：简明，易读，无二义性。
（2）缩进：4个空格，不用Tab键是因为在不同的情况下显示的长度可能不一样。
（3）行宽：限定为100字符。
（4）括号：在复杂的条件表达式中，可以清晰地表示逻辑优先级。
（5）断行与空白的{}行：断行在程序调试时可以清晰的表达变量的变化情况，{}来判断程序的结构。
（6）分行：不要把多个变量定义在一行上。
（7）命名：
①在变量名中不要提到类型或其他语法方面的描述。
②避免过多的描述。
③如果信息可以从上下文中得到，那么此类信息就不必写在变量名中。
④避免可要可不要的修饰词。
（8）下划线：用来分割变量名字中的作用域标注和变量的语义。
（9）大小写：
①所有类型/类/函数名都用Pascal形式（所有单词第一个字母都大写）。
②所有变量都用Camel形式（第一个单词全部小写，随后单词用Pascal形式）。
③类/类型/变量：名词或组合名词。
④函数则用动词或动宾组合词来表示。
（10）注释：注释是为了解释程序做什么（What），为什么这样做（Why）以及要特别注意的地方。
2、代码设计规范
（1）概念：代码设计规范不光是程序书写的格式问题，而且涉及到程序设计、模块之间的关系、设计模式等方方面面，又有不少内容与具体程序设计语言息息相关（如C，C++，JAVA，C#），但是也有通用的原则。
（2）函数：原则：只做一件事，并且要做好。
（3）goto:函数最好有单一出口，为了达到这一目的，可以使用goto。
（4）错误处理：
①参数处理：在Debug版本中，所有的参数都要验证其正确性，在正式版本中，对从外部（用户或别的模块）传递过来的参数，要验证其正确性。
②断言：验证正确性就要用断言。
（5）如何处理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、代码复审：看代码是否在代码规范的框架内正确的解决了问题。代码复审的形式包括：自我复审、同伴复审、团队复审。
4、结对编程：结对编程中有两个角色：领航员和驾驶员。在个人编写的过程中，很多人喜欢根据个人喜好来规定代码规范，而且存在的bug自己难以发现，因此，在结对编程时，我们可以互换角色，在开始写代码之前，规定两个人都认可的一套代码规范，并且不间断地进行复审，以减少软件中存在的问题，修复bug，提高软件质量。
任务2：两两*结对，对结对方《实验二 软件工程个人项目》的项目成果进行评价
（1）对项目博文作业进行阅读并进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，将以上评论内容发布到博客评论区。
结对方博客链接
结对方Github项目仓库链接
对结对方博客的评论
（2）克隆结对方项目源码到本地机器，阅读并测试运行代码，参照《现代软件工程—构建之法》4.4.3节核查表复审同伴项目代码并记录。
代码核查表
（3）依据复审结果尝试利用github的Fork、Clone、Push、Pull request、Merge pull request等操作对同伴个人项目仓库的源码进行合作修改。
结对方项目仓库中的Fork、Clone、Push、Pull request、Merge pull request日志数据
任务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）外的任意有效平台功能实现。
本项目的PSP
| PSP | 任务内容 | 计划共完成需要的时间(min) | 实际完成需要的时间(min) |
|---|---|---|---|
| Estimate | 计划 | 30 | 30 |
| Estimate | 估计这个任务需要多少时间，并规划大致工作步骤 | 30 | 30 |
| Development | 开发 | 2585 | |
| Analysis | 需求分析 (包括学习新技术) | 20 | |
| Design Spec | 生成设计文档 | 30 | |
| Design Review | 设计复审(和同事审核设计文档) | 10 | |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 5 | |
| Design | 具体设计 | 900 | |
| Coding | 具体编码 | 1440 | |
| Code Review | 代码复审 | 180 | |
| Test | 测试（自我测试，修改代码，提交修改） | 120 | |
| Reporting | 报告 | 30 | |
| Test Report | 测试报告 | 10 | |
| Size Measurement | 计算工作量 | 10 | |
| Postmortem & Process Improvement Plan | 事后总结 ,并提出过程改进计划 | 30 | 30 |
小结感受：两人合作真的能够带来1+1>2的效果吗？通过这次结对合作，请谈谈你的感受和体会。
通过本次合作我觉得两个人合作做项目比一个人独自做效果要好很多。在项目完成方面，结对编程会带来1+1>2的效果，在编写程序遇到问题时，可以及时的向同伴求助，特别感谢我这次的结对编程伙伴李小龙同学。我在写程序时遇到好几个问题都是他帮我解决的。通过这次合作我真真体会到了结对编程的乐趣和互相督促的进步。结对编程还可以找出自己代码的不足之处，以及版本的兼容问题。比如在我的的电脑上字体显示正常，结果到编程伙伴的电脑上出现乱码，通过这种相互测试，可以更好的优化自己的程序。再次特别感谢李小龙同学。在结对过程我也看到了自己能力上的缺陷，以前学习的时候重视理论课而疏于实践课，导致和别人在动手实践上面的差距，需要及时的弥补自己。同时算法方面我真是欠缺太多，在面对这样的问题时缺乏思路，因此今后我需要补习算法方面的知识，加强软件课程的学习，在遇到任何问题时都能有一个正确的思路。