我的項目《四則運算題目生成程序》分析總結

1、Planning：

PSP2.1	Personal Software Process Stages	Time
Planning	計劃
· Estimate	· 估計這個任務須要多少時間	2h
Development	開發
· Analysis	· 需求分析 (包括學習新技術)	2h
· Design Spec	· 生成設計文檔	1h
· Design Review	· 設計複審 (和同事審覈設計文檔)	1h
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	30min
· Design	· 具體設計	1h
· Coding	· 具體編碼	3h
· Code Review	· 代碼複審	1h
· Test	· 測試（自我測試，修改代碼，提交修改）	3h
Reporting	報告
· Test Report	· 測試報告	1h
· Size Measurement	· 計算工做量	30min
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	1h
	合計	17h

 

2、Development：

一、需求分析

對題目中的要求進一步剖析，明確要注意的點以及須要進一步明確的技術等。

1. 參數內容的獲取方式
2. 按照算術表達式的生成語法規則來進行構造和解析，空格將做爲分隔符號，而且應該注意需求345的約束條件
3. 對於重複問題，先判斷結果是否相同，結果相同再判斷他們是否可以經過有限次的交換來轉化
4. 將題目和答案分別記錄到相應的文件中去
5. 對給定的題目和答案文件進行斷定，須要解析題目的語法

二、生成設計文檔

a) 類的建立：

i. 根據計算的需求，在這個項目中須要對天然數和分數進行運算，那麼就有必要建立一個新的類用於表示天然數和分數

因而設計一個class Item，其主要的成員變量是 denominrator(分母)和numerator(分子)；

而後重載+-*/這四個運算符來實現計算；

同時還有一個關鍵的函數是toString()，用於方便後面放進具體的表達式中。

ii. 最終是爲了生成表達式，那麼就須要建立一個表達式類class Expression

其主要的成員curValue 來記錄當前表達式的值，expressionString用於記錄表達式的字符串形式，level用於記錄當前表達式有多少個運算符，lastoperator用於記錄最後一個運算符的類型；

同時爲了後面可以判斷表達式是否重複，還分別記錄了表達式中各類運算符號的個數，而且將生成過程當中的子表達式的值也給保留了；

而後在構造函數中，須要的參數是數的範圍以及運算符的數目，具體的表達式構造方式請見下一部分。

b) 表達式的生成方式：

主要是根據表達式中運算符的數目，利用遞歸的方式從更簡單表達式（運算符數目更少）生成。好比2運算符-表達式能夠用1運算符-表達式加上一個符號一個操做數來生成。因而，我決定採用的方式是：先生成1-運算符的表達式，再用它去生成2-運算符表達式，而後再考慮生成3-運算符表達式。這個生成順序也是個人計算順序，至關於先 生成的表達式我都保證運算時優先，這時候若是它的最後運算是加減法我就加上括號。

這樣一來生成的表達式的值我就可以很好地把控住。

c）如何判斷重複，以及如何解決參數要求是否可以知足：

用排列組合的方法也只能差很少推導出上界和下界，然而好像並不能很好得去肯定是否可以生成足夠的不重複表達式。因此我仍是偏向於從機率的角度，若是連續生成的好幾個新的表達式都被判斷出與已有的表達式重複，則說明可能差很少沒法再生成不重複的表達式，就直接終止程序。

而如何重複就是用個人表達式對象中的各個參數進行比較，若是都相等，這個時候重複的機率很是大，因此直接捨去。

d) 對於檢驗對錯：

就是解析字符串，先將中綴表達式轉換成後綴表達式，而後將後綴表達式進行求值，這個過程當中利用了棧以後將很好完成。

三、設計複審

四、代碼規範

（這兩個方面在實際過程當中幾乎是隱藏在和同窗們的交流和討論中的，沒有很嚴肅嚴格得進行這兩個環節）

五、具體編碼

這個過程是整個項目開發中費時最多的環節，而後也是煩惱最多的部分，遇到了不少細節問題和bug。具體有如下幾個方面：

a) 字符問題：因爲考慮輸入輸出中有extend ASCII， 也就是× 和÷ 號，因此在處理過程仍是費了不少時間去弄明白它們在char, char*和string中的存儲方式，最後試驗以後仍是發現使用起來比較方便。

b) 運算方面的細節問題：有一些表達式的邏輯沒能處理得很好，而後有一些漏洞，最後在分析計算結果的時候花費了較大的時間。

這個方面我以爲可能之後注意在開發的過程當中注意單元測試，而後儘可能在小規模代碼下將基本問題解決，可能會有利於問題的解決。

c) 涉及語言的熟悉度方面的問題。（在點滴中消耗了不少時間）

六、代碼複審

主要是debug，而後解決的分別是字符問題，輸入輸出問題，運算正確度問題。

七、測試（這個部分也是我判斷本身程序正確性的初步環節）

首先測試各類參數組合形式的輸入。

再來是嘗試生成表達式，而且抽樣檢查是否規範。

接下來是輸入特定組合的表達式，檢查求值狀況。

多輪下來，最後發現基本沒有什麼問題。

3、性能分析與優化

 

在分析性能的時候選的參數是-n 10000 -r 20

在性能問題上主要是後期生成的每一個表達式都須要與前面生成的大量表達式進行判重。能明顯覺察到後期生成表達式的速度變慢了。

爲了可以進一步優化的時間的複雜度，能夠選擇考慮用新的結構將表達式組織起來，從而可以更快的判斷是否重複。

通過和同窗們的討論發現，其實有幾個同窗採用的就是打表的方式，每生成一個表達式劃掉一個值，這樣判斷重複就快多了。

 

總結：

實際的使用時間

PSP2.1	Personal Software Process Stages	Time
Planning	計劃
· Estimate	· 估計這個任務須要多少時間	1h
Development	開發
· Analysis	· 需求分析 (包括學習新技術)	2h
· Design Spec	· 生成設計文檔	2h
· Design Review	· 設計複審 (和同事審覈設計文檔)	1.5h
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	1h
· Design	· 具體設計	2h
· Coding	· 具體編碼	6h
· Code Review	· 代碼複審	1h
· Test	· 測試（自我測試，修改代碼，提交修改）	3h
Reporting	報告
· Test Report	· 測試報告	1h
· Size Measurement	· 計算工做量	0.5h
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	2h
	合計	23h

4、收穫與感悟

一、關於程序存在的幾點漏洞說明：

a) 對程序的輸入格式要求比較嚴格

好比在檢驗四則運算的正確性這個環節，個人程序的讀入方式要求在序號的「n.」後面緊跟着一個空格，而後再是表達式或者答案。

其實這個問題在使用過程當中仍是會存在一些問題的，由於沒有給用戶進行提示說明就將輸入的格式限制住了，其實對用戶體驗來講不是很好，下一輪要改正這個缺陷。

b) 在性能上面存在一些缺陷

在這裏比較表達式是否重複其實是O(n²)的複雜度，或許能夠採用某些特殊的方式在這裏進行優化。

二、關於項目開發的計劃、設計與實現方面的體會：

我我的的體會是計劃當然是很是重要的，可是在現階段我的能力以及經驗仍是明顯不夠的，因此在對項目各個階段用時的估計上面會過度樂觀，結果反而容易形成在開發過程當中對時間的把控顯得不夠，影響整個開發的節奏。

而後是設計與實現，設計應當細化到什麼程度呢？

這是我一直很疑惑的問題。通過這麼屢次的相似項目（做業）的實踐經歷，我想我認識到了一點，對我我的來講，必定要勇敢去實踐，由於對我我的來講，我喜歡將不少東西放到腦殼裏面而後讓它不斷髮酵，同時讓本身在有意無心中去產生靈感、好的想法來解決問題，這種方式有時當然可以帶來不少驚喜，可是同時也讓我愈來愈不重視編碼的這個過程，而實際上在編程過程當中不管是語言工具的使用仍是算法的運用方面都會遇到一些小的阻礙。

因此我認爲現階段我給本身定的提升方法是：增長敏捷度。提升設計的效率，而後在實現的過程當中去不斷碰到問題解決問題。有時不是要越過問題，而是要經過對相關問題理解認識來旁敲側擊，從而在主要問題上面有新的理解和認識。因此要習慣於專一編程的過程，在這個過程當中不斷優化設計，不但迴歸理論和知識，而後甚至屢次迭代。

毛主席《實踐論》中的哲理也能夠用到設計和具體實現過程當中來，要二者不斷補充，從而使提升開發效率，提升產品質量。

三、在我的習慣和心態方面的感悟

看到有的同窗作的PSP安排和規劃，確實感受到了軟件工程師的我的習慣和態度在很大程度上會決定它的項目是否可以順利在預期時間內完成，而且在很大程度上會影響產品的質量。

發現本身確實在從此這門課的學習上面要更加投入一些，珍惜此次鍛鍊的機會，藉助此次課的機會好好體驗軟件開發以及團隊合做，開發出讓人滿意的產品。