一.項目時間規劃與實際用時
PSP2.1 |
Personal Software Process Stages |
預計時間/h |
實際時間/h |
Planning |
計劃 |
|
|
· Estimate |
· 估計這個任務需要多少時間 |
15 |
20 |
Development |
開發 |
|
|
· Analysis |
· 需求分析 (包括學習新技術) |
2 |
2.5 |
· Design Spec |
· 生成設計文檔 |
0.5 |
0.5 |
· Design Review |
· 設計復審 (和同事審核設計文檔) |
0.5 |
0.5 |
· Coding Standard |
· 代碼規范 (為目前的開發制定合適的規范) |
0.2 |
0.2 |
· Design |
· 具體設計 |
3 |
4 |
· Coding |
· 具體編碼 |
6 |
10 |
· Code Review |
· 代碼復審 |
2 |
2 |
· Test |
· 測試(自我測試,修改代碼,提交修改) |
2 |
5 |
Reporting |
報告 |
|
|
· Test Report |
· 測試報告 |
1 |
1 |
· Size Measurement |
· 計算工作量 |
0.2 |
0.2 |
· Postmortem & Process Improvement Plan |
· 事后總結, 并提出過程改進計劃 |
1 |
1 |
合計 |
16.4 |
26.9
|
這次寫代碼我覺得我收獲還是很大的,從不熟悉一個語言到感覺可以順暢使用,是一件很棒的事情,從以前的編代碼的經歷來說 ,這應該是我編過比較順利并且很有成就感的程序啦,第一是因為我這次作業很認真的并且獨立思考的連貫編寫,以及我后續的認真調試都是一步步走出來的,感覺以前老是交給我們的東西,真正成為了成果留在了我們的腦海里,也讓我們在編程的過程中更加得心應手。不過這次作業遺憾的就是我還是沒能實現所有的功能,而且有些地方的算法其實還是蠻復雜很浪費空間時間的,如果有機會的話,我會加善我的程序,并且更認真的反思我的代碼編寫的問題。
二.改進程序性能
在程序改進的過程中,我大致用了四個小時吧,首先要從思路上進行優化,由于我自己的思路有時候總是會繞個彎子,要了可能性就丟失了很多效率,但是有時候可能性自己也不能夠很好的處理好,另外就是改代碼的過程總是會出很多問題,編譯器在編譯的時候丟了個大括號總是不報警!所以這也是我從VS 2012的使用中得出的教訓,寫代碼一定要有一個良好的架構。其次比較花時間的就是調試了,畢竟我寫的代碼總會有一定漏洞,在調試的過程中真的花費了很多很多的時間。
我的程序思路就是通過隨機數的生成,然后去判斷我需要多少符號,根據符號去判斷我需要多少個數字,然后依次生成我要的東西,拼湊成一個前綴表達式,并且最后將前綴表達式轉化為中綴表達式進行輸出。
優化思路的時候我主要想到了三點:
第一:我們在運算中出現問題的時候都是出現了負數,首先我先從數字的排序上進行了規定,在一定程度上可以避免負數的出現,其次如果在運算中還是出現了負數,那么我們將減號替換為加號或者是其他符號,這樣子可以剔除了出現負數的情況,也讓四則運算符合了題目的要求。
第二:當我們式子中出現了除以0的情況,這個情況也是類比上一條,我們生成一個隨機數,并且是符合題目要求的隨機數,然后替換,再進行運算。
第三:題目中還有另一個要求就是我們不能夠生成重復的表達式,那么我們其實可以直接就生成不會出現重復的表達式,從而避開繁雜的檢查判重操作。我為生成的數字和符號的前綴序列規定了數字降序的排列,同時利用表達式的哈希值來去除完全相同的表達式,因為表達式中的運算數遵從有序性,所以程序不會同時產生3+2+1,1+3+2這兩個表達式,只會生成3+2+1,這一點可以完全排除表達式重復的情況。
三.發現的bug
其實我發現在運算的過程中我們使用的int類型完全不夠支撐我們r比較大的時候的運算,所以我轉而使用了long類型,不過其實用無符號int64會更好~但是我當時好像有點蠢,就沒有修改。
四.個人總結
這次軟件工程的開發讓我切身實際感受到了現在作為一個計算機學院大三學生的一個非常有趣的地方, 就是自己可以寫一寫比較高難度的程序,對我個人能力的提高有很大的幫助,例如思路的建立呀,代碼的優化呀,這些都會給我很大的幫助。
參與軟工工程的過程中,我覺得自己也在語言的匯編上得到了很大的提高,覺得自己可以很快在短時間內運用一個新的語言,對我來說真的是很棒的一件事,也讓我覺得自己有很大的成長和收獲。
文章列表