• 第二次结对编程作业


    avatar

    1.导航


    博客链接

    队友本作业博客链接

    Github


    2.具体分工

    • 我负责前、后端与博客撰写
    • 队友负责算法

    3.PSP表格

    PSP2.1 Personal Software
    Process Stages
    预估耗时(min) 实际耗时(min)
    Planning 计划 60 90
    Estimate 估计这个任务需要多少时间 90 120
    Development 开发 600 1200
    Analysis 需求分析
    (包括学习新技术)
    90 120
    Design Spec 生成设计文档 60 90
    Design Review 设计复审 60 90
    Coding Standard 代码规范
    (为开发制定合适的规范)
    60 60
    Design 具体设计 60 120
    Coding 具体编码 480 600
    Code Review 代码复审 120 240
    Test 测试
    (自我测试,修改,提交修改)
    180 240
    Reporting 报告 90 120
    Test Report 测试报告 30 60
    Size Measurement 计算工作量 20 20
    Postmortem & Process
    Improvement Plan
    事后总结
    并提出过程改进计划
    30 30
    合计 2030 3200

    4.解题思路与设计实现

    i. 网络接口的使用

    • 没什么可说的,用POST请求注册、登录,拿到登录响应返回的token,附加在开局和出牌的Header里即可。

    ii.代码组织与ii内部实现设计(类图)

    iii.算法的关键与关键实现部分流程图

    • 运用了贪心算法,先判断特殊牌型,如果是则直接提交。每次从剩余手牌中挑出最大的那个组合,加入预提交列表并从手牌中移除,递归地执行上述步骤,直到墩数等于三。最后把剩余手牌按小到大插入后墩、中墩、前墩,以满足要求。


    5.关键代码解释

    牌型的处理中顺子是最不好处理的,所以贴一下这部分的代码。

    • 先把手牌切割成多个严格递增的序列:

    • 顺子有可能重合,如果满足条件,可以将其合并。如下图所示:

    • 如果出现花括号中的组合,例如:456789和5678,就可以合并。根据长的那个顺子的长度和5的差值(这里6和5的差值是1,所以从下标1开始就可以合并),可以得到开始合并的下标。具体实现:


    6.性能分析与改进

    i.改进思路

    • 把匹配到的牌型从剩余手牌中移除时,重复执行获取顺子等函数,这些函数的调用有时是不必要的,可以找条件跳过。
    • 之前为了方便,找对子/三条/炸弹时,都是重新遍历手牌。其实可以在第一次遍历手牌时,就记录对子/三条/炸弹的位置,以便直接取用。
    • 合并顺子数组可以用链表,速度更快。

    ii.性能分析图、消耗最大的函数


    从图中可以看出,除了系统调用外,最耗时的函数是getShunzi(),即上面提到的获取顺子。


    7.单元测试

    • 部分单元测试代码

    • 主要测试CardAI类中的solve函数,该函数是解题的核心部分,实现了上面所说的解题过程。

    • 覆盖率

    • 构造数据的思路:疯狂调用服务器的api获取手牌,solve后提交。如果服务器返回不合法,则记录这次的手牌,人工分析出牌存在哪些问题并解决。


    8.Github代码Commit记录


    9.遇到的异常、困难及解决办法

    • 问题描述:“葫芦>同花>顺子>三条”这个规则一开始并没注意到,致使算法里的"三条"一开始直接利用"葫芦"里现成的判断,然后就一直被吃分也出现了很多的相公情况。同时中后墩大小的考虑只以两墩牌面最值进行单次比较,没有考虑最值相等下要顺序比较第二大值等以此类推,表示写在最值相同的情况下比较第二大的牌面太困难麻烦了(放弃)。

    • 做过的尝试:对于“三条”的判断只能回头返工重新在顺子判断筛完后单独再判断“三条”。虽然也就是跟“葫芦”里的判断类似,但也花了不少时间(可能还是我太菜了。

    • 解决情况:除了最后实在不想再写多次比较或者说不会写多次比较,其他都算解决了吧。。了吧。。吧。。

    • 收获: 想的还是太少,也太懒,总想拿现成的东西来实现,导致被疯狂吃分。虽然最后也是拿写好的“葫芦”来改成“三条”hhhh,但这不影响我总结收获。

    • 10/16更新:困难已解决,之前考虑的都是在把同花加入提交列表的时候选择顺序,然而其实可以在提交之后交换顺序。


    10.评价你的队友

    • 值得学习的地方:tql!! 前、后端通吃,对于只会写c++的我只能说拉了后腿了。而且时间把控的都很好,基本都是他催着我前进。
    • 需要改进的地方:真的tql!! 有一说一,确实,没什么需要改进的,嗯是这样的。

    11.学习进度条

    第N周 新增代码
    (行)
    累计代码
    (行)
    本周学习耗时
    (小时)
    累计学习耗时
    (小时)
    重要成长
    1 0 0 7 7 学会了Axure的基本使用
    2 0 0 0 0
    3 0 0 15 22 Python和PyQt5的基本使用
    4 4200 4200 50 72 学会了使用Visio画类图、流程图
  • 相关阅读:
    R语言 dbWriteTable 写入数据库 为空和乱码问题
    data.table进阶
    简述ODS,和数据仓库做简单的比较
    深入ff and ffbase
    R语言操作mysql上亿数据量(ff包ffbase包和ETLUtils包)
    基于mondrain 的原理纠正特殊指标值
    基于mondrian聚合表的R计算olap开发
    dplyr快速入门
    R中的data.table 快速上手入门
    删除pentaho用户和用户文件夹
  • 原文地址:https://www.cnblogs.com/fzu-Z9h/p/11681701.html
Copyright © 2020-2023  润新知