第二次結對編程

第二次結對編程

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。

相關文章
相關標籤/搜索
本站公眾號
   歡迎關注本站公眾號,獲取更多信息