第二次結對程式設計總結

標籤：could   apt   sp2   c++   編碼   capture   能力   尋找   需求分析   

第二次結對程式設計總結

成員： 陳燦  劉澤 王子博 

github地址：https://github.com/USTC-ASE-P10/wf

 PSP表格

PSP2.1	任務內容	計劃完成需要的時間(min)	實際完成需要的時間(min)
Planning	計劃	30	30
Estimate	估計這個任務需要多少時間，並規劃大致工作步驟	30	30
Development	開發	670	590
Analysis	需求分析 (包括學習新技術)	20	30
Design Spec	產生設計文檔	30	30
Design Review	設計複審 (和同事審核設計文檔)	30	10
Coding Standard	代碼規範 (為目前的開發制定合適的規範)	30	20
Design	具體設計	40	40
Coding	具體編碼	360	300
Code Review	代碼複審	60	40
est	測試（自我測試，修改代碼，提交修改）	100	120
Reporting	報告	190	210
Test Report	測試報告	60	60
Size Measurement	計算工作量	30	30
Postmortem & Process Improvement Plan	事後總結 ,並提出流程改善計劃	100	120
Summary	合計	890	830

 實驗要求

第0步：輸出某個英文文字檔中26個字母出現的頻率，由高到低排列，並顯示字母出現的百分比，精確到小數點後面兩位。
第一步：輸出單個檔案中的前 N 個最常出現的英語單詞。
第二步: 支援 stop words。
第三步: 我們想看看常用的短語是什麼， 怎麼辦呢？
第四步：把動詞形態都統一之後再計數。

 How you collaborate: working separately? pair programming? VS Live Share? other style?

一開始是兩人結對，一人領航，一人駕駛；後來的大部分工作，兩人領航，一人駕駛。

 How do you discuss design guideline, coding convention and reach agreement?

我們的編碼風格主要是PEP8，然後編碼時是三個人討論具體的實現細節，然後王子博對於我一些不合風格的寫法會給予糾正，比如空格換行這些格式之類的。

 How did the two of you aim high and try to deliver the optimal result with your own time constraints? is this the best your could do? what prevent you from doing your best?

我們三個人克服了一些阻礙，抽出了一定的連續時間來合作；這不是我們能做到的最好結果，因為我們的時間精力是有限的，還有很多公司的事情，生活上的事情需要處理。

 List 3 strengths and 1 weak area of your partner

劉澤：
1.腦子轉得快，在先驗知識比較豐富的前提下，對於很多數理邏輯問題，能給予很快的反饋
2.解決實際問題能力強
3.對新事物的學習能力很強
4.平時編碼少，經驗不足，我也有同樣的弱點，希望能在接下來的一段時間提升自己的engineering能力

王子博：
1.對python語言有比較深刻的認識
2.領導以及表達能力優秀，能合理安排團隊的工作
3.編碼規範，工程能力強
4.據本人說，從未用過C++，理由好像是不接觸自己無法精通的領域，我反而覺得可以多去嘗試一下，不必拘泥於必須精通，嘗試過程中可能會有所改觀。

 How do you use profile tools to find the performance bottleneck and improve speed? show some screenshots of your analysis

使用了Pycharm中profile進行效能分析，測試的配置是:

wf.py -f -n 10 C:\Users\v-checan\Desktop\pride-and-prejudice.txt

即統計pride-and-prejudice.txt中出現頻率前10的單詞，得到的效能分析結果：

可以看到，我們的wf.py主體是main函數，main函數裡面的__init__(),parse_args各佔0.8%的時間，負責初始化和參數解析，顯然這部分也不是我們的主體。我們在統計詞頻這個功能中調用最多的是word這個函數，然後我們再分析這個函數裡面的情況：lower()佔用6.2%的時間，sorted佔用7.0%的時間，open佔用0.0%的時間，read（）佔用6.2%的時間；真正的大頭在於findall函數，我們這裡採用了正則匹配的方法去找到符合我們要求的詞，但是這樣其實我們很難在這裡面進行最佳化，除非我們根據文本的內容以及我們要尋找的實際邏輯來重新細化寫一個函數，但是這樣的話，會顯得很複雜。
接下是我們具體的數字形式的效能分析結果：

 單元測試

利用python的unitest進行我們的單元測試，具體代碼可以訪問我們github地址：https://github.com/USTC-ASE-P10/wf/blob/master/tests.py

 

第二次結對程式設計總結