201871010106-丁宣元 实验三 结对项目—《D{0-1}KP 实例数据集算法实验平台》项目报告
作者:互联网
项目 | 任务 |
---|---|
课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/2018CST/ |
这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/14604444.html |
我的课程学习目标 | 1.练习Github的Fork、Clone、Push等基本操作; 2.自主学习基础的遗传算法; 3.锻炼与同伴的合作能力,学习同伴的长处,互相促进。 |
这个作业在哪些方面帮助我实现学习目标 | 1.熟悉Github操作 2.利用汉堡包法合作开发沟通 3.了解遗传算法 |
结对方学号-姓名 | 201871010109-胡欢欢 201871010114-李岩松 |
结对方本次博客作业链接 | 链接1 链接2 |
本项目Github的仓库链接地址 | 链接 |
一、实验目的与要求
-
体验软件项目开发中的两人合作,练习结对编程(Pair programming)。
-
掌握Github协作开发程序的操作方法。
二、实验内容和步骤
-
任务1:阅读《现代软件工程—构建之法》第3-4章内容,理解并掌握代码风格规范、代码设计规范、代码复审、结对编程概念;
- 代码风格规范:简明,易读,无二义性(如下表所示:该表依照邹欣老师博客总结)
代码规范 标准 缩进 4个空格 行宽 100字符 括号 括号表示逻辑优先级 断行与空白的{ }行 每个“{”和“}”都独占一行 分行 不要把多行语句放在一行,不要把不同的变量定义在一行上 命名 匈牙利命名法(见邹欣老师《构建之法》附录B(第337页)) 下划线问题 分隔变量名字中的作用域标注和变量的语义 大小写问题 多个单词组成的变量名:Pascal-所有单词的第一个字母都大写;Camel-第一个单词全部小写;
所有的类型/类/函数名都用Pascal形式,所有的变量都用Camel形式;
函数用动词或动宾组合词注释 用来解释程序做什么(What),为什么这样做(Why),以及要特别注意的地方的;复杂的注释应该放在函数头; - 代码设计规范:程序书写的格式问题,程序设计、模块之间的关系、设计模式。
代码设计规范 标准 函数 只做一件事,要做好 goto 函数要有单一的出口,可以使用goto 错误处理 参数处理,断言 - 代码复审:查看代码是否在“代码规范”的框架内正确地解决了问题。最基本的复审手段,就是同伴复审。
- 复审的目的在于:
(1)找出代码的错误:编码错误;不符合项目组的代码规范的地方。
(2)发现逻辑错误。
(3)发现算法错误。
(4)发现潜在的错误和回归性错误。
(5)发现可能改进的地方。
(6)教育(互相教育)开发人员,传授经验,让更多的成员熟悉项目各部分的代码,同时熟悉和应用领域相关的实际知识。
- 复审的目的在于:
- 结对编程:一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘,同一个鼠标一起工作,一起分析,一起设计,一起写测试用例,一起编码,一起单元测试,一起集成测试,一起写文档等。
- 互相提意见:影响,反馈
-
任务2:两两自由结对,对结对方《实验二 软件工程个人项目》的项目成果进行评价,具体要求如下:
- 对项目博文作业进行阅读并进行评论
- 由于班内特殊情况,经老师同意后三人为组,按照转圈方式评论博文和复查代码。经讨论后决定:我复查胡欢欢同学的博文和代码。
博客链接 | 评价链接 | 结对方Github项目仓库链接 |
---|---|---|
https://www.cnblogs.com/1763088787h/p/14604500.html | https://www.cnblogs.com/1763088787h/p/14604500.html | https://github.com/123321hu/DP- |
- 克隆结对方项目源码到本地机器,阅读并测试运行代码。
-
克隆结对方项目源码
-
阅读测试运行后,完成复查表如下:
首先,胡欢欢同学的代码风格非常规范,每一块都有非常详细的注释,方便同伴理解审查,在代码中明显可以感觉到思路流畅清晰。其次,胡欢欢同学的作业中包含使用文档。最后,在Github上进行了八次commit。在阅读胡欢欢同学的代码后,我的收获颇丰,深刻认识到自己在的不足,我会努力学习借鉴。 -
代码核查表
-
1. 概要部分 | 代码能符合需求和规格说明么? 代码设计是否有周全的考虑? 代码可读性如何? 代码容易维护么? 代码的每一行都执行并检查过了吗 |
符合 基本周全 可读性好 比较容易维护 已一行一行执行检查 |
---|---|---|
2.设计规范部分 | 设计是否遵从已知的设计模式或项目中常用的模式? 有没有硬编码或字符串/数字等存在? 代码有没有依赖于某一平台,是否会影响将来的移植? 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现?在本项目中是否存在类似的功能可以调用而不用全部重新实现? 有没有无用的代码可以清除? |
遵循 没有 代码在pycharm上运行,但不依赖平台 存在类似功能可以调用 没有 |
3.代码规范部分 | 修改的部分符合代码标准和风格么? | 符合 |
4.具体代码部分 | 有没有对错误进行处理?对于调用的外部函数,是否检查了返回值或处理了异常? 参数传递有无错误,字符串的长度是字节的长度还是字符(可能是单/双字节)的长度,是以0开始计数还是以1开始计数? 边界条件是如何处理的?Switch语句的Default是如何处理的?循环有没有可能出现死循环? 有没有使用断言(Assert)来保证我们认为不变的条件真的满足? 对资源的利用,是在哪里申请,在哪里释放的?有没有可能导致资源泄露?有没有可能优化? 数据结构中是否有无用的元素? |
处理异常 无 未发现死循环 没有 没有资源泄露 |
5.效能 | 代码的效能(Performance)如何?最坏的情况是怎样的? 代码中,特别是循环中是否有明显可优化的部分? 对于系统和网络调用是否会超时?如何处理? |
效能良好,达到了具体任务的要求 没有 不会超时 |
6.可读性 | 代码可读性如何? 有没有足够的注释? |
可读性好 足够注释 |
7.可测试性 | 代码是否需要更新或创建新的单元测试? | 暂时不需要 |
-
依据复审结果尝试利用github的Fork、Clone、Push、Pull request、Merge pull request等操作修改同伴个人项目仓库源码。
操作 效果 fork 分叉、克隆 出一个(仓库的)新拷贝 Clone 使用git来进行版本控制时,为了得一个项目的拷贝(copy),需要知道这个项目仓库的地址 Push 将本地版本库的分支推送到远程服务器上对应的分支,一般形式为 git push <远程主机名> <本地分支名> <远程分支名> 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);- 知识储备:
- 遗传算法引入:模拟达尔文生物进化论的自然选择和遗传学机理的生物进化过程的计算模型,是一种通过模拟自然进化过程搜索最优解的方法。该算法通过数学的方式,利用计算机仿真运算,将问题的求解过程转换成类似生物进化中的染色体基因的交叉、变异等过程。
- 基本操作:(1)复制:个体位串根据其目标函数f拷贝自己的过程;
(2)交叉:新复制产生的位串个体随机两两配对;随机选择交叉点对匹配的位串进行交叉繁殖,产生新的位串;
(3)变异:某个字符串当中某一位值得偶然的随机改变。 - 流程图:(摘自教师分享的内容:百度文库某文章)
- 需求分析陈述。
本次实验包含以下需求:
嵌入D{0-1}KP实例求解算法
在线绘制散点图、回溯算法求解、动态算法求求解等
利用遗传算法求解D{0-1}KP问题-
软件设计说明。
- 本次实验采用前后端分离思想,前台用AmazeUI前端框架+ThinkPHP3.1.3框架,后端采用python的flask框架设计,后台去调用Pyton接口。在项目目录结构中,static静态资源,src存放源代码,upload测评文件与代码,app.py为程序主文件。
- 代码规范说明(补充):
- 本次实验采用前后端分离思想,前台用AmazeUI前端框架+ThinkPHP3.1.3框架,后端采用python的flask框架设计,后台去调用Pyton接口。在项目目录结构中,static静态资源,src存放源代码,upload测评文件与代码,app.py为程序主文件。
-
软件实现及核心功能代码展示:
-
程序运行:程序运行时每个功能界面截图。
(1)回溯算法
(2)散点图
(3)测评
-
描述结对的过程:线上讨论
-
提供此次结对作业的PSP。
PSP
- 知识储备:
PSP2.1 | 任务内容 | 计划共完成需要的时间(h) | 实际完成需要的时间(h) |
---|---|---|---|
Planning | 计划 | 0.5 | 0.5 |
·Estimate | · 估计这个任务需要多少时间,并规划大致工作步骤 | 0.5 | 0.5 |
Development | 开发 | 22 | 30 |
·· Analysis | 需求分析 (包括学习新技术) | 8 | 9 |
· Design Spec | ·生成设计文档 | 1 | 0.9 |
·Design Review | ·设计复审 (同伴再次审核设计文档) | 0.5 | 0.5 |
·Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 1 | 1 |
·Design | 具体设计 | 1.5 | 2 |
·Coding | 具体编码 | 7 | 12 |
·Code Review | ·代码复审 | 1 | 2 |
·Test | 测试(自我测试,修改代码,提交修改) | 2 | 3 |
Reporting | 报告 | 2 | 3 |
··Test Report | ·测试报告 | 1 | 1.5 |
·Size Measurement | 计算工作量 | 0.5 | 1 |
·事后总结。并提出过程改进计划 | 0.5 | 0.5 |
- 小结感受:思考两人合作是否可以达到1+1>2的效果。
总体来说,我觉得达到了1+1>2的效果。由于特殊原因,本组是三人组,但是在完成作业的过程中,我们每个人首先都对作业进行理解和学习,商讨确定采用的开发方式和分工。确定之后,按照分工实施工作。在遇到问题后,虽然有时会存在一些分歧,但经过讨论,最终我们达成一致。虽然每个人解决问题的思维方式都存在差异,但是经过良好的讨论后,可以成为思维的拓展。
标签:丁宣元,结对,201871010106,代码,项目,0.5,算法,实验,链接 来源: https://www.cnblogs.com/budinge/p/14630602.html