201971010110-高杨 实验三 结对项目—《{0-1}KP 实例数据集算法实验平台》项目报告

项目内容

项目	内容
班级博客链接	https://edu.cnblogs.com/campus/xbsf/2019nwnucs
作业要求	https://edu.cnblogs.com/campus/xbsf/2019nwnucs/homework/12560
课程学习目标	（1）体验软件项目开发中的两人合作，练习结对编程（Pair programming）。 （2）掌握Github协作开发软件的操作方法。
这个作业在哪些方面帮助我实现学习目标	（1）对实验二进行复盘，同时改进实验二的不足之处。 （2）学会与他人合作完成项目，增长团队合作经验。 （3）学习观摩他人的优秀经验，认识到他人的长处与自身的不足。
结对方	201971010111-何晨泽
结对方本次博客作业链接	https://www.cnblogs.com/eggsy/p/16053916.html
本项目Github的仓库链接地址	https://github.com/EggsyHo/EX3

任务一

内容：阅读《现代软件工程—构建之法》第3-4章内容，理解并掌握代码风格规范、代码设计规范、代码复审、结对编程概念。

第三章—软件工程师的成长

1：软件开发的工作量和质量怎么衡量呢?第2章提到的PSP认为有下列4个因素:

• （1）项目1任务有多大?
• （2）花了多少时间?
• （3）质量如何?交付的代码中有多少缺陷?交付有两个定义:

•      在代码完成(Code Complete)时,  交付给测试人员。
  

•      在软件最终发布时，交付给顾客。
  

• （4）是否按时交付？

2：软件工程师的思维误区？

• （1）分析麻痹
• （2）不分主次，想解决所有依赖问题
• （3）过早优化
• （4）过早扩大化/泛化

第四章—两人合作

1：复审

•  结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设  计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。
  

•  开发中的复审主要包括:设计复审、代码复审、测试计划复审和文档复审。
  

• 这些复审可以在伙伴之间进行，也可以在团队内部进行。结对编程和传统开发过程的复审有什么区别呢?
• 1.传统意义上的伙伴复审，即程序员之间的互相复审，有以下的问题:
• 1)复审人缺乏对程序的深人了解，减弱了复审的效果;
• 2)不能持久、定时地进行复审;
• 3)对需求和设计的不了解导致无法实现全面有效的复审。
• 团队复审是指多于两人的团队就某一程序实体进行的复审，团队复审的缺点在于:
• 1)什么时候开会做复审?不可能一个团队天天开会。要找到一个所有人都能出席的时间， 并不容易;
• 2)牵涉的人员众多，理解程度不一，复审的速度和效果不能得到有效的平衡一太快则 有人不懂，太慢则浪费许多人的时间;
• 3)正是由于成本问题，无法对所有的设计和代码进行深人的复审;
• 4)由于人员众多，有面子问题。

2：如何结对编程？

• 驾驶员:写设计文档，进行编码和单元测试等XP开发流程。
• 领航员:审阅驾驶员的文档;监督驾驶员对编码等开发流程的执行;考虑单元测试的覆盖率;思考是否需要和如何重构;帮助驾驶员解决具体的技术问题。领航员也可以设计 TDD中的测试用例。
• 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。
• 主动参与。任何一个任务都首先是两个人的责任，也是所有人的责任。
• 只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不 管在分析、设计或编码上，双方都拥有平等的决策权利。
• 设置好结对编程的环境，座位、显示器、桌面等都要能允许两个人舒适地讨论和工作。如 果是通过远程结对编程，那么网络、语音通讯和屏幕共享程序要设置好。

任务二

内容：两两自由结对，对结对方《实验二 软件工程个人项目》的项目成果进行评价。

项目	内容
结对方	201971010111-何晨泽
结对方博客链接	https://www.cnblogs.com/eggsy/p/16000499.html
结对方Github项目仓库链接	https://github.com/EggsyHo/201971010111_HCZ_EX2

博客评论：

• 1：博文结构：文章结构严丝合缝，整齐有致，在排版上近乎无可挑剔。
• 2：博文内容：作者完美完成了项目的所有要求，对于各任务都有详细的描述，内容详细充实，近乎完美。
• 3：博文结构与PSP中“任务内容”列的关系：博文结构与“任务内容”成功对应。
• 4：PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究：相较于计划共完成需要的时间，作者实际完成的时间更短一些，从中也可以看出作者的时间分配能力，精准的分配使得时间得到了最大效益的利用。

检测项目：

• 将项目导入IDEA进行测试（如图）：
  
  
• 由图所见，结对方完美完成了项目的所有要求：
  
  

代码核查表

项目	内容
概要部分
代码符合需求和规格说明么？	是
代码设计是否考虑周全？	是
代码可读性如何？	非常好
代码容易维护么？	易维护
代码的每一行都执行并检查过了吗？	是
设计规范部分
设计是否遵从已知的设计模式或项目中常用的模式？	是
有没有硬编码或字符串/数字等存在？	有
代码有没有依赖于某一平台，是否会影响将来的移植？	对移植无影响
开发者新写的代码是否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以通过调用而不用全部重新实现？	是
有没有无用的代码可以清除？	无
代码规范部分
修改的部分符合代码标准和风格么？	符合
具体代码部分
有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？	已处理
参数传递有无错误，字符串的长度是字节的长度还是字符的长度，是从0开始计数还是从1开始计数	无错误；字符的长度；从0开始
边界条件是如何处理的？switch语句和default分支是如何处理的？循环有没有可能出现死循环？	前提分析推导边界条件；不可能
有没有使用断言来保证我们认为不变的条件真的得到满足？	否
对资源的利用，是在哪里申请，在哪里释放的？有无可能存在资源泄露？有没有优化的空间？	有对应的申请、释放语句；不存在；有
数据结构中有没有用不到的元素？	无
效能
代码的效能如何？最坏的情况是怎么样的？	效能优秀；一般情况下不会出现卡顿的现象
代码中，特别是循环中是否有明显可优化的部分？	无
对于系统和网络的调用是否会超时？如何处理？	否
可读性
代码可读性如何？有没有足够的注释？	注释多且详细，代码清晰，可读性良好
可测试性
代码是否需要更新或创建新的单元测试？	是

结对方项目仓库中的日志数据

• 如图所示，对结对方的项目进行了fork操作
  
  

任务三

内容：采用两人结对编程方式，设计开发一款{0-1}KP 实例数据集算法实验平台，使之具有以下功能：

• （1）平台基础功能：实验二 任务3；
• （2）{0-1}KP 实例数据集需存储在数据库；
• （3）平台可动态嵌入任何一个有效的{0-1}KP 实例求解算法，并保存算法实验日志数据；
• （4）人机交互界面要求为GUI界面（WEB页面、APP页面都可）；
• （5）查阅资料，设计遗传算法求解{0-1}KP，并利用此算法测试要求（3）；
• （6）附加功能：除（1）-（5）外的任意有效平台功能实现。

需求分析：

• （1）可以读入文件。
• （2）可以正确画出所需的散点图。
• （3）至少具有实验二所拥有的三个算法（贪心算法，回溯算法，动态规划算法）。
• （4）可以对任一组{0-1}KP数据按重量比进行非递增排序。
• （5）文件得以保存。
• （6）设计遗传算法求解{0-1}KP。
• （7）人机交互界面为GUI界面（利用web实现）。
• （8）{0-1}KP 实例数据集存储在数据库。
• （9）平台可动态嵌入任何一个有效的{0-1}KP 实例求解算法，并保存算法实验日志数据。

软件设计说明：

• 技术框架
  
  前端：Layui
  
  后端：Maven,Spring Boot
  
  数据库：MySQL
• 前端界面
  
  

核心功能代码展示：

• 功能介绍图
  
  

• 遗传算法展示

点击查看代码

<div class="layui-layout-admin" style="background-color: #00F7DE">
    <div th:insert="~{index::top}"></div>
    <div th:insert="~{index::left}"></div>
    <div class="layui-body" style="background-color: #eeeeee">
        <script id="toolBarTable">
            &nbsp;&nbsp;遗传算法-文件列表<br>
            <button class="layui-btn" lay-event="fileSelected">
                选择该文件
            </button>
        </script>
        <div style="font-size: medium;">
            <table id="tableShow" class="layui-table" lay-filter="testTable">

            </table>
        </div>
        <script id="toolbar">
            运行结果
        </script>
        <table id="tableGroup" class="layui-table" lay-filter="groupTable">

        </table>
    </div>
</div>

• 日志记录

点击查看代码

<div class="layui-layout-admin" style="background-color: #00F7DE">
    <div th:insert="~{index::top}"></div>
    <div th:insert="~{index::left}"></div>
    <div class="layui-body" style="background-color: #eeeeee">
        <div style="padding: 15px;">
            <table id="tableShow" class="layui-table" lay-filter="testTable">

            </table>
        </div>
    </div>
</div>

程序运行：

• 在打开文件运行后，首界面如图所示：
  
  
• 数据上传（选择beibai4.in）
  
  
• 显示数据（拓展项目）
  
  
• 绘制散点图
  
  
• 排序
  
  
• 算法求解（动态规划算法）
  
  
• 导出文件
  
  
• 文件保存结果
  
  
• 日志结果
  
  
• 数据库中留存的记录
  
  
  
  

结对过程：

• 在本次结对项目中，我们采用了汉堡包法进行沟通协商。
  
  
  
  
  
  

PSP：

PSP2.1	任务内容	计划共完成需要的时间(min)	实际完成需要的时间(min)
Planning	计划	10	8
- Estimate	- 估计这个任务需要多少时间，并规划大致工作步骤	10	8
Development	开发	783	749
- Analysis	- 需求分析（包括学习新技术）	40	30
- Design Spec	- 生产设计文档	20	18
- Design Review	- 设计复审	8	6
- Coding Standard	- 代码规范	15	10
- Design	- 具体设计	40	45
- Coding	- 具体编码	500	480
- Code Review	- 代码复审	40	30
- Test	- 测试（自我测试，修改代码，提交修改）	120	130
Reporting	报告	60	58
- Test Report	- 测试报告	30	25
- Size Measurement	- 计算工作量	10	13
- Postmortem & Process Improvement Plan	- 事后总结，并提出过程改进计划	30	30

github提交

小结感受：

在本次结对项目中，本人有幸与何晨泽同学一起完成这项任务，经过不懈努力，我们最后成功的完成了本次实验，通过合作的方式，确实产生了1+1>2的效果，也对以后的学习产生了启迪。