第二次结对编程

第二次结对编程

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。

 

posted @ 2018-11-02 20:02  大海的味道*  阅读(243)  评论(0编辑  收藏  举报