• 第二次结对编程


    第二次结对编程

    Github

    合作方式

    我们的合作方式采取pair coding和 separate coding相结合的方式。刚开始的讨论设计,分配功能,建立GitHub仓库是一起做的,伙伴搭建好了框架,互相分配好要实现的函数,通过GitHub源码管理,进行分头编程。当遇到框架/关键函数/目标功能等问题时候进行讨论,pair coding解决

    讨论内容

    1. Design Guideline: 我们根据目标讨论了一下大致的代码结构,根据讨论好的函数分工搭好框架即可完成design guideline,分头行动即可。
    2. Coding Convention: 由队友写好了函数接口,之后只要按需求完成函数即可,命名按全部小写约定。
    3. Reach agreement: 我们分别提出了一些方案,选择理论上最快的实现,之后如果有改动的想法只需要跟队友通报一声push即可。

    评价我的队友

    优点:

    • 经验丰富,搭建框架使用代码解决问题能力非常优秀
    • 非常愿意分享经验知识
    • debug能力十分优秀

    缺点:

    说话不够逗

    单元测试与回归测试

    • 单元测试:我们在 model.py 为每一个功能定义了专门的函数,一些共同的事情交给utils.py专门子函数负责,因此我们从 utils.py 开始测试每一个子函数,之后测试模块函数即可
    • 回归测试:每增加一个新的功能带来之前公用的utils.py子函数的改变,测试一下之前的功能正常就可以了,因此我们去掉了最基础的 utils.py 里面的支持函数的测试,整合到了 coverage_test.py 中。

    代码覆盖率测试

    我们使用了coverage包进行回归测试

    结果如下:

    时间控制与效能分析

    我们使用 python 的 cProfile 进行效能分析,根据最初稿的时间效能分析我们做了两次优化,以下是队友的分析与工作:

    优化前:

    发现用时最长是modes.py的listcomp操作,队友发现他存stopword使用了list而不是set,增加了查找效率

    改变之后 效果如下:

    发现listcomp时间 -0.13s,改变非常有效!

    之后是我的测试与改变:

    测试前:

    根据结果发现耗时最多的是get_phrases子函数,作用是从一句话中截取短语,经过对之前源代码的分析

    结果多增加了一个tuple,多了没必要的pop操作,于是进行了以下优化:

    结果如下显示:

    get_phrases 函数运行时间 -0.08s 效果显著

    时间总结

    根据结果输出,-n 10 -p 2 -v verbs.txt下时间已经缩小到0.27s,我们使用nltk函数库进行从list到dic并且sort的操作,cProfile输出显示最多时间为build-in函数,而经过大文件的测试,时间结果基本符合O(nlgn)增长,之前有过多次文件操作导致时间很慢,已经通过优化代码逻辑立刻解决掉了,并没有存为commit。

  • 相关阅读:
    DripRoad(点滴之路)
    如何写优雅的代码
    .Net 一直在改变
    Protobufnet的完美解决方案
    关于msgpack序列化后的消息包是否再压缩
    失眠
    创建一个比微软性能更好空间更少的GUID
    msgpack与protobuf的简单性能测试对比
    分布式游戏服务器的登陆流程
    对象池的实现与性能测试
  • 原文地址:https://www.cnblogs.com/yqsyqs/p/9892189.html
Copyright © 2020-2023  润新知