第二次结对编程

第二次结对编程

Githubcss

合做方式

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

讨论内容

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

评价个人队友

优势:

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

缺点:

说话不够逗node

单元测试与回归测试

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

代码覆盖率测试

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

  
  
  
  

结果以下:git

  
  
  
  

 

时间控制与效能分析

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

优化前:web

  
  
  
  

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

  
  
  
  

改变以后 效果以下:编程

  
  
  
  

发现listcomp时间 -0.13s,改变很是有效!bootstrap

 

以后是个人测试与改变:

测试前:

  
  
  
  

根据结果发现耗时最多的是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。

相关文章
相关标签/搜索
本站公众号
   欢迎关注本站公众号,获取更多信息