| 這個作業屬于哪個課程 | <2021春軟體工程實踐_W班 (福州大學)> |
|---|---|
| 這個作業要求在哪裡 | <軟工實踐寒假作業2/2> |
| 這個作業的目标 | <1.閱讀《建構之法》并提問2.完成詞頻統計個人作業> |
| 作業正文 | 見下方目錄 |
| 其他參考文獻 | 菜鳥教程-python學習 CSDN-fork與pull request CSDN-測試用例如何提高代碼覆寫率 CSDN-python使用unnitest測試 CSDN-元典排序 知乎-計算機領域的大牛、大神們（包括曆史上的以及現在的）有哪些奇聞轶事？ |
GitHub位址：詳情
作業基本資訊 2021-3-3...
目錄：
-
任務一
Question1-Chapter3軟體工程師的成長
Question2-Chapter3軟體工程師的成長
Question3-Chapter5
Question4-Chapter8需求分析
Question5-Chapter8需求分析
Question6-Chapter9項目經理
Question7-Chapter4兩人合作
附加題
-
任務二
GitHub項目位址
PSP表格
解題思路描述
代碼規範制定連結
設計與實作過程
性能改進
單元測試
異常處理說明
心路曆程與收獲
提問
我閱讀了第三章關于初級軟體工程師成長的5個小點（P49），對于其中的積累問題領域的知識和經驗和提升職業技能這兩點感觸頗深，但對于同樣成長的初級工程師如何去量化這兩個方面的提升呢（作為學生）？還是說這樣的積累是在工作崗位中不斷累積最終形成職業的晉升呢？這兩個點的掌握程度上級可以通過面試評估出來但作為學生的我們又需要如何去提升它們呢？
A:我個人認為初級軟體工程師的成長有小部分在于學生階段的培養，很大部分在于工作崗位中不斷積累的能力。我更傾向于一種說法 在學校裡學會學習的能力，在社會運用學習的能力
我閱讀了第三章練習與讨論中第四個問題。（如下圖）我認為這是在程式開發過程中難以避免的問題，然而我們該 如何降低這種問題發生的頻率 呢？（個人認為前期的面向對象分析與設計是很重要，可是沒有投入到實際實踐中空于理論一定是會産生偏差的。即使是我在完成學生成績系統時，寫到後面也會發現備援的可能影響篇幅巨大的需要修改的地方。）
寒假作業2/2
A:在設計前期先确立一個面向對象系統，然後進行評估測試，在設計出一個demo時通過調查問卷的形式修改系統設計。到後期如果依舊出現這個問題，還是選擇重新設計再度修改，否則後期的新的修改可能會産生新的影響。希望能夠有其他的回答方向…（再重新回來看認為這個問題有些鑽空洞式的回答，畢竟無法去準确評估形勢與情況）
我閱讀了第五章對于團隊模式的集中分類後，認為功能團隊模式是最符合成熟的軟體開發流程的，然而究竟是是團隊創造項目還是項目主導團隊，我依舊對此感到難以權衡。
A:等到團隊成熟後應當是項目主導團隊，因為懂得擅長之處能夠快速高效；在團隊初成立時還是應當遵循項目經理的規劃走。之是以提出這個問題，是因為在一次賽前我與一位同學交談，那個時候我們小組尚未确定選題，但是那位同學和我說其實是組長想要做什麼項目為此去選擇符合他的隊員，最終得到一個适合這一項目的團隊進行開發，讓我思考了許久。
我閱讀了第八章需求分析，在其中筆者提及調差問卷式的提問具有兩個關鍵疏漏：實際答案并非我們所希望得到的答案（例：選擇最喜歡的搜尋引擎，使用者給的回答可能是使用最頻繁的）以及容易帶有引導性。于是筆者引導我們去正确的設定調差問卷評估使用者需求。然而個人以為，不論是一個新産品的問世還是一個新需求的呈現，無非都是具有極其強烈引導性的，因為我們要抓住使用者的痛點，擴大化其痛點。與其不停的讓痛點使用者模糊的表述需求，似乎選擇先行制造界面再引導使用者修改效率更高？誠然，這樣做會使得軟體可能需要進行大規模修改，然後選擇題和主觀題是不是選擇題更容易作答些。但換句話來說這兩種方式皆有利有弊，個人偏向于先做demo再詢問，私以為效率更高些。
A:已在問題中給出個人了解。
我閱讀了第八章需求分析中的功能分析四象限，對于其中的殺手功能有一些疑惑。我曾經想要開發一個類似于收集衣服搭配的軟體，然而在我的不斷設想中（當時還沒有接觸産品學習）我所謂的功能在不斷的增加，新的功能（虛拟試衣）會覆寫之前的功能成為“殺手功能”，可慢慢的我發現這一新出功能慢慢的成為了這個軟體中篇幅最大的内容，或者說他的内容超過了原先我認為的使用者痛點（也就是搭配子產品）。如果出現這種情況我們又該如何應對呢？就像我們常說根據使用者需求或是軟體發展添加新功能後，慢慢地隐蔽了原先的亮點。一個軟體功能的擴充是必不可少的，可如果失去了主次會不會就像沒有初心的人逐漸喪失競争力一般。
A:我個人認為在設計時如果有更沖擊的思想點都可以再重新規劃重點；如果确立中心了就不必再添加了。然而對這個問題還是請求助教老師能夠給予我答複。
回顧這一問題後，我個人認為成熟的産品經理可能就能夠合理的規避掉這一問題了。不懂得取舍，系統過于龐大沒有重點，那這個軟體也就沒有了亮點，雖然提供了便捷。專且精才是迎合大衆的點。但是不可置否，在未來軟體成熟後一定會有系統化的增加功能的使用者回報，那麼到那個時候該如何應對呢？
在小組開會的過程中，我們總是會抓住很小的但是重要的點讨論非常久的時間，但整個主流架構都沒有讨論清楚，花大量的時間在重要的末流過多的浪費了開會的時間，作為項目經理該如何去規避這個問題發生的頻率呢？
A:可能提前做好會議大綱會能夠起到一些幫助，但還是不足以解決。本質上，開放式的思考回答與獨斷式的思考回答有利有弊，但針對于項目初期，這兩種方式我并不能明确哪種方式更好。
在第四章中看到這句話 結對程式設計中駕駛員和領航員的角色要經常互換，避免長時間緊張工作而導緻觀察力和判斷力下降？
A:可能加強溝通交流也可以起到相應效果。角色互換在生活中似乎很少見到。
附加題
附加題
來源：知乎
寒假作業2/2
自我小結
自我小結
任務二-WordCount程式設計
一、GitHub項目位址：詳情
二、PSP表格
| PSP | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 30 | 30+20(後又重新規劃) |
| • Estimate | • 估計這個任務需要多少時間 | 60 | |
| Development | • 開發 | 660 | 600 |
| • Analysis | • 需求分析 (包括學習新技術) | 90 | 120 |
| • Design Spec | • 生成設計文檔 | 40 | |
| • Design Review | • 設計複審 | 20 | |
| • Coding Standard | • 代碼規範 (為目前的開發制定合适的規範) | ||
| • Design | • 具體設計 | ||
| • Coding | • 具體編碼 | ||
| • Code Review | • 代碼複審 | 90(尋求性能優化) | |
| • Test | • 測試（自我測試，修改代碼，送出修改） | 180 | 300 |
| Reporting | 報告 | 100 | |
| • Test Repor | • 測試報告 | ||
| • Size Measurement | • 計算工作量 | 10 | |
| • Postmortem & Process Improvement Plan | • 事後總結, 并提出過程改進計劃 | ||
| 合計 | 1600 | 1630 |
1.首先解決檔案讀入問題。先編寫了一個打開檔案并将檔案内容輸出到控制窗的函數，并測試通過。
2.編寫函數架構，确立了幾個計算檔案行數、字元數、單詞總數及輸出檔案單詞前十的函數功能。
#啟動WordCount
def count_file(file1,file2)
#讀取檔案内容并輸出到控制台 該函數測試通過後已删除
#def read_file(filename)
#将字元串s輸出到指定檔案路徑
def out_file(filename,s)
#清空指定檔案内容
def clear_file(filename)
#統計檔案的總字元數
def count_chars(file_name)
#計算檔案中每一行的字元數
def count_line_chars(content)
#統計檔案的有效行數
def count_lines(file_name)
#将檔案内容轉換為單詞元組
def analy_word(file_name)
#統計檔案的單詞總數（對應輸出第2行）
def count_word(file_name)
#統計檔案中的各單詞出現次數
def count_words(file_name)
3.填充函數。進一步複習python文法，然後根據相關函數補齊功能，并通過自定義的方式測試函數的正确率。
4.通過main函數進行測試，将需要輸出的内容輸出到控制窗中。編寫一個input.txt作為測試用例。
5.将原本輸出到控制窗的内容輸出到output檔案中。
6.将功能子產品化，并進行相應的修改與性能提升。
7.進行測試。
8.回顧與總結。
代碼規範
在代碼規範制定時，我發現在整個程式書寫完畢後最容易産生不比對的便是空行和注釋的填寫。還沒有養成良好的代碼即寫即加注釋的習慣，需要繼續努力。
将函數列舉出來然後實作。
1.實作計算檔案總字元數的函數的關鍵代碼
通過将檔案中的每一行内容通過轉換成set函數形式然後計算該set的長度，最後添加。
#打開檔案 将每行的字元數相加 然後傳回字元串
with open(file_name,"r",encoding='utf-8') as file_obj:
for content in file_obj:
c_cs += count_line_chars(content)
#計算檔案中每一行的字元數
result = 0
for i in set(content):
result = result + int(content.count(i))
2.實作計算檔案有效行數的函數的關鍵代碼
将檔案的每一行通過strip函數将換行符'\n'切割下來，以避免計算了空行，然後通過len函數計算實際的有效行數。
#統計檔案的有效行數
for line in f:
line = line.strip('\n')
if len(line) == 0:
continue
s += 1
3.實作提取檔案詞數的函數的關鍵代碼
一開始我将計算單詞總數和單詞詞頻的函數分開來，後來複查代碼時，為了提高函數速度提取出來。
通過compile函數和strip函數将文章中的單詞劃分好，再通過lower函數将其中單詞最小化，用split函數将空格提取。在words元典中不斷添加word，并且重新将words中重複的添加到一起。最後将words元典傳回。
def analy_word(file_name):
words = {}
r = re.compile(r"[,!\*\.]")
with open(file_name, "r",encoding='utf-8') as f:
for line in f:
for word in r.sub("", line.strip()).lower().split(" "):
if word in words:
words[word] += 1
words.setdefault(word, 1)
return words
4.實作計算文章單詞數量的函數的關鍵代碼
将傳回的words元典，通過sum函數将每個values時添加起來。
#統計檔案的單詞總數（對應輸出第2行）
words = analy_word(file_name)
result = sum(words.values())
5.實作計算文章單詞詞頻的函數的關鍵代碼
将words元典采用lambda函數按values降序，按key降序排序。最後輸出前十的單詞數和出現次數。
#統計檔案中的各單詞出現次數
words = analy_word(file_name)
words2 = copy.deepcopy(sorted(words.items(), key=lambda k:(k[1],k[0]),reverse=True))
m = 0
s = ""
for i in words2:
if (m<10):
s += str(i[0])+":"+str(i[1])+"\n"
m+=1
仔細檢視了代碼後認為能夠提升性能的便是給字元排序的性能提升和錄入字元的性能提升。錄入字元可采用正規表達式進行分割（但在網絡上查閱正規表達式尚不了解，寫出來有bug存在故沒有進行改動），字元排序采用快速排序替代冒泡排序，可提升性能。
1.0個字元
2.10個字元寒假作業2/2 3.100個字元寒假作業2/2 4.1000個字元寒假作業2/2 5.10000個字元寒假作業2/2 6.100000個字元寒假作業2/2 7.1000000個字元寒假作業2/2 寒假作業2/2
1.實作統計檔案字元數函數的測試
str内包含了特殊字元，測試了\t \r \n 三個字元的字元數皆為1。
def test_count_char(self):
str = "I have! a \t \r brother? \n"
...
#系統測試
WordCount.count_file(dir,"output_count_char.txt")
#單獨測試
WordCount.clear_file("s_output_count_chars.txt")
WordCount.out_file("s_output_count_chars.txt",s)
2.實作統計檔案行數函數的測試
測試了\t和\n的差別，以及有效行數的判斷，若單純為\t一行不包含其他字元，也預設為1行。
str = "hello\nworld\t\nwwwwI \thave! a \t \r brother? \naaaaa\n"
...
#系統測試
WordCount.count_file(dir,"output_count_line.txt")
#單獨測試
WordCount.clear_file("s_output_count_line.txt")
WordCount.out_file("s_output_count_line.txt", s)
3.實作統計檔案詞數和詞頻的測試
測試了特殊字元是否會被記為單詞。
str = "I have! a \t \r brother? \n He is four years older than me. "
WordCount.count_file(dir,"output_count_word.txt")
str = "I have a brother.have a brother. He is four years older than me. Now he is fifteen years old， and he is a student of Grade Nine. He is tall and handsome. His classmates like playing with him. He works hard in study. His teachers speak highly of him. Besides， basketball and running are his favorites."
#系統測試
WordCount.count_file(dir, "output_count_words.txt")
#單獨測試
WordCount.clear_file("s_output_count_word.txt")
WordCount.out_file("s_output_count_word.txt", s)
WordCount.clear_file("s_output_count_words.txt")
WordCount.out_file("s_output_count_words.txt", s)
使用Coverage計算測試覆寫率：
如何優化測試覆寫率：
通俗而言，采用完整業務流程進行測試，采用特定情況流程進行測試，要使得測試點覆寫所有流程就能夠達到較高的覆寫率。函數本身有太多的檔案打開異常判斷，但由于檔案打開異常判斷無法提取到函數前方，因為檔案打開異常有可能随時發生。其他由于字元串為空的判斷是根據檔案打開異常所寫的，但由于打開異常便會自動結束程式是以也無法走到，應當修改這一塊的代碼。
由于暫時隻考慮到檔案打開異常和檔案不存在異常。
采用try-except語句，當檔案不存在時報出異常并終止程式。
1.重新溫習了python基礎文法，重點溫習了檔案輸入輸出相關函數。
2.針對出現的錯誤進行debug，然後發現很多錯誤出現在編碼方式裡，有python等級不夠的問題也有python自身編碼方式的問題，最終修改成功。gebug果然需要耐心與細心才能完成，中間通過百度、尋找同學進行幫助，最終終于解決bug。
3.針對幾個函數的填充，我采用了python自帶的相應函數。相比而言，python真的比其他語言代碼長度簡短清晰。
4.子產品化的編碼方式改變了我以往喜歡在main函數裡“大刀闊斧”的排版方式，轉變成精短的main函數構造，并且在測試檔案中的引用也确實使得這個py檔案能夠廣泛被調用。
5.單元測試子產品不斷地發現bug尋找解決方式，然後再發現bug…在這一子產品中我發覺了前期規劃的不夠仔細，函數中的細微差錯和編碼方式問題。這種種問題令我不斷的重新返工修改函數。在這一子產品花費的時間與我想象中的差距很大，也讓我真正的意識到測試的重要性，僅僅是一個小小的WordCount檔案就需要我不斷的返工修改，以達到相對的順利，那麼未來那些複雜的檔案便更需要我們的“無差錯”，更需要單元測試的完善與系統化。