结对编程总结

(这是现代软件工程课程第二周的结对编程总结作业,编程项目是黄金点游戏 AI

需要说明的是,仓库中只有我的 commit,是因为最初我们认为这个不到一百行的脚本不需要使用 Git 仓库管理。后期我打包了数据文件,又编写了简单的测试脚本,为了让大家易于下载项目中的文件,才建立了仓库。实际上每个组员都有贡献。

在开始实现之前,用PSP表格记录下你预估完成项目需要的时间。

这个问题不适用于我们的项目,因为我们仅仅开了个会,然后大家一起写了一两百行的脚本,很多步骤并不存在。另外,在这个作业发布时我们已经开始开发了,项目执行中也没能记录实际耗时。

看教科书和其他资料中关于Information Hiding, Interface Design, Loose Coupling的章节,说明你们在结对编程中是如何利用这些方法对接口进行设计的。

我们在会议中讨论了程序整体架构——主程序处理输入输出、载入所有策略、对所有策略进行评分,并用得分最高的策略进行预测;中间一小段由另一位组员编写,来动态增减策略(此段代码后期被移除);第三位组员生成初始的策略。大家同意了策略都表示为 50 维权向量,并默认采用 numpy.array 对象,就分别开工了。

描述重要模块接口的设计与实现过程。设计包括代码如何组织,比如会有几个类、几个函数,他们之间的关系是如何的,关键函数是否需要画出流程图?说明你的算法的关键(不必列出源代码),以及独到之处。

我们认为下一个黄金点是之前 50 个黄金点的线性组合,所以用历史点乘一个权向量即可得到预测值。程序做的事情就是从预先生成的几千个权向量(也就是几千个预测策略)中找出最好的来用,这些策略是一位组员用手工编写的脚本或机器学习以往的比赛数据生成的。

predict 函数接受最多 50 项的历史黄金点记录和一个 50 维权向量,预测下一个黄金点。score 函数接受一个权向量,用最近 8 个黄金点来检查它的预测表现,对其进行打分。

main 函数读入所有策略(权向量),再读入历史黄金点对所有策略进行评分,并输出得分最高的两个策略的预测值。它还会以小概率输出 99

阅读有关UML的内容。画出UML图显示计算模块部分各个实体之间的关系(一个图即可)。

这个问题不适用于我们的项目,因为我们没有用对象,甚至几乎没有用函数,逻辑就在几十行的 main 函数中。

Design by Contract的内容,描述这些做法的优缺点,说明你如何把它们融入结对作业中。

这个做法以增加一些文档和开发时间为代价,换来了更高质量的对象和过程。如果每个对象和过程的行为都被明确记录,会使得理解程序所有可能的执行流更加容易(这也是为什么人们认为程序设计语言包含“类型”的概念是必要的,甚至函数式编程要求函数绝对没有副作用,也绝对不产生异常)。我们没有使用这个做法,而是采用了非常宽松的程序设计——数据文件用 numpy.loadtxt 读取,几乎接受任何输入格式;函数也没有对参数类型作出假设,而是按 duck type 的思想直接使用合适的运算符进行运算。

程序的代码规范、设计规范。你们俩如何达成共识、采用什么规范?程序中是否有异常处理?你如何处理各种异常?

在开会时我们确定了基本逻辑,其他规范是隐式的,如 PEP8 规定了代码规范,NumPy 也有广为接受的数据表示和处理的规范。程序中没有异常处理,因为这个程序的工作环境非常确定,不需要适应复杂的用户输入,不太可能发生异常。不过测试脚本因为用来测试主程序,做了异常处理,以尽可能严格地模拟实际比赛平台对我们提交的程序的要求。

描述界面模块的详细设计过程。你的程序有用户界面么?在博客中详细介绍你如何设计你的界面模块。

没有用户界面,只有机器界面,程序通过文件读写来和外界交互。

描述界面模块与其他模块的对接。详细描述UI模块的设计与其他模块的对接,并在博客中截图实现的功能。界面/控制/数据模块体现了MVC的设计模式了么?

这个问题不适用于我们的项目,因为我们没有用户界面,只有一个非常简单的机器界面。

描述结对的过程。提供两人在讨论的结对照片。遮挡和美化都是允许的。

我们在拿到这个题目并组队的那天晚上,在讨论室开了个会决定程序架构和基本逻辑(并未拍照)。因为大家有事,第二天起组员在地理上就都不在一起了,大家分别按照开会时决定的分工完成了自己的部分,并在即时聊天中交换了工作。

看教科书和其他参考资料中关于结对编程的章节,说明你们采用了哪种合作方式,以及结对编程的有点和缺点。a) 结对的每个人的优缺点在哪里(需列出至少三个优点和一个缺点)?b) 你如何说服你的伙伴改进他/她的缺点?请考虑一下三明治方法。

这个问题不适用于我们的项目,因为我们没有进行严格意义上的结对编程,而是把任务分成了三个部分,大家分别完成,并由我最终运行了测试。考虑到这个项目的规模非常小,我认为不足以表现出每个人的优缺点。

在你实现完程序后,请在PSP表格中记录下你在开发各个步骤上实际花费的时间。说明差异的原因。

这个问题不适用于我们的项目,原因同上文。

其他收获。例如,如何攻克技术难点,你做了哪些阅读和探索,可以把资料和经历描述一下。如果你的项目是和其他同学一起比赛(例如比赛速度),描述一下你的程序和其他程序的优劣。

这是一个比赛,我们最终取得了第二名,但我觉得这个结果意义不大,因为我相信这个比赛在数学上很混沌,获胜者有相当大的随机性。最让我们满意的事实是我们只用了相当简单的模型和相当少的编码时间,就写出了表现达到一般水平的程序,事半功倍~

posted @ 2018-10-19 18:55  机智的超立方体  阅读(240)  评论(6编辑  收藏  举报