軟工實踐第二次作業-黃紫儀
1)Github項目地址
https://github.com/ziyi12345/shudu2.git
2)在開始實現程序之前,在下述PSP表格記錄下你估計將在程序的各個模塊的開發上耗費的時間
PSP2.1 |
Personal Software Process Stages |
預估耗時(分鐘) |
實際耗時(分鐘) |
Planning |
計劃 |
30 |
|
· Estimate |
· 估計這個任務需要多少時間 |
30 |
|
Development |
開發 |
260 |
|
· Analysis |
· 需求分析 (包括學習新技術) |
60 |
|
· Design Spec |
· 生成設計文檔 |
10 |
|
· Design Review |
· 設計復審 (和同事審核設計文檔) |
10 |
|
· Coding Standard |
· 代碼規範 (為目前的開發制定合適的規範) |
10 |
|
· Design |
· 具體設計 |
30 |
|
· Coding |
· 具體編碼 |
60 |
|
· Code Review |
· 代碼復審 |
20 |
|
· Test |
· 測試(自我測試,修改代碼,提交修改) |
60 |
|
Reporting |
報告 |
60 |
|
· Test Report |
· 測試報告 |
20 |
|
· Size Measurement |
· 計算工作量 |
10 |
|
· Postmortem & Process |
· 事後總結, 並提出過程改進計劃 |
30 |
|
合計 |
|
350 |
|
3)解題思路描述
最開始拿到題目的時候已經10號了,剛開始整個人都是傻的因為完全沒反應的過來。後來開始趁著吃飯路上慢慢把思路理清了一下。才開始有了頭緒。
數獨來說,主要分成兩個大部分
(1)數獨的生成:得有數據生成,而且要有一定的隨機性(總不能都是一個數獨結果)
(2)數獨的實現判斷:主要來說分成3塊:
1,每一行不能有重復的數字;
2,每一列不能有重復的數字;
3,每一個小的九宮格裏面不能有重復的數字;
總的來說前面兩點比較容易實現,畢竟一個for循環就能解決的問題。第三點的話有點小麻煩。因為先要想辦法確認出每次輸入的那個數獨點屬於哪個小號的九宮格。這裏需要額外的加入判定條件進行處理,然後判斷成立了填入格子內。然後完成一個點的判斷後利用遞歸思想向後一列移動,一行全部填完就切到下一行第一列,不能滿足就返回上一層。直至全部表格填好。(有越界判定,當j>9之後,說明已經進入第10行,越界會判定完成退出。)
4)設計實現過程
按照上述的思路來看,我的代碼函數主要是2部分(解題部分),一個是判斷函數bool get_arr(int i,int j),它用來生成一個隨機數並且確定它能否放置在這個位置,第二部分是啟動函數void start(),它用來初始化整個數獨表(第一個位置為5,因為(1+3)%9+1=5,其余部分初始為0,然後從(1,2)開始數獨生成,同時內部也負責生成隨機數的種子,保證數獨的隨機性),main 函數用來接受CMD給出的參數N,然後輸出N個隨機結果到指定txt文件裏面去(輸出函數就沒有單獨拿出去做一個函數了。偷偷省事)
5)代碼說明
以下是數獨判斷部分的代碼以及部分相關解釋:
6)測試運行。
7)記錄在改進程序性能上所花費的時間,描述你改進的思路,並展示一張性能分析圖,並展示你程序中消耗最大的函數
VS還沒搞定所以性能分析可能得晚一點。不過目前來說最大的函數應該還是那個判斷函數,畢竟還要隨機生成,很有可能生成到重復的數字。再去循環判斷就可能會很麻煩。
至於改進的話,我覺得在隨機這部分,是否可以考慮用當前隊列來負責存每一行可以輸入的數字,然後填入一個就從隊列中拿掉該數字放到已使用的隊列中。然後在剩余的當前隊列中選擇下一個數字繼續判斷。這樣的話可以解決掉重復的問題,而且可以跟行檢測放在一起處理。簡化步驟。
8)PSP 2.1表格
PSP2.1 |
Personal Software Process Stages |
預估耗時(分鐘) |
實際耗時(分鐘) |
Planning |
計劃 |
30 |
20 |
· Estimate |
· 估計這個任務需要多少時間 |
30 |
20 |
Development |
開發 |
260 |
620 |
· Analysis |
· 需求分析 (包括學習新技術) |
60 |
180 |
· Design Spec |
· 生成設計文檔 |
10 |
10 |
· Design Review |
· 設計復審 (和同事審核設計文檔) |
10 |
10 |
· Coding Standard |
· 代碼規範 (為目前的開發制定合適的規範) |
10 |
10 |
· Design |
· 具體設計 |
30 |
30 |
· Coding |
· 具體編碼 |
60 |
60 |
· Code Review |
· 代碼復審 |
20 |
20 |
· Test |
· 測試(自我測試,修改代碼,提交修改) |
60 |
300 |
Reporting |
報告 |
60 |
70 |
· Test Report |
· 測試報告 |
20 |
30 |
· Size Measurement |
· 計算工作量 |
10 |
10 |
· Postmortem & Process |
· 事後總結, 並提出過程改進計劃 |
30 |
30 |
合計 |
|
350 |
710 |
9)遇到的困難與收獲
emmmmmm,題目本身感覺還好,原來畢竟也接觸過https://zhidao.baidu.com/question/350480313遞歸判斷,理理還是勉強弄得清楚,然後最開始的話是隨機數那邊出現了問題,最開始是使用當前時間做得隨機數種子,結果每一次測試,都是生成的同一個數獨,下一次就是另一個數獨表重復N次的那種,然後自己去把種子值進行點處理,讓他每次循環都能變動一下。這樣輸出的結果還是比原來隨機的多了一點。不過裏面還是容易有重復的。最後還是百度到了用
long long myrand()
{__asm("RDTSC");}
來生成隨機數(據說是納秒級的,隨機賊強。)鏈接:https://zhidao.baidu.com/question/350480313
然後最開始的時候每個點的測試也不是用的隨機,而是循環1-9去判斷的(能省個變量呢,理直氣壯),於是直接導致基本上我看第2個數字就能確定這兩個數獨表是不是一樣的。(後來感覺這隨機的也太有規律了,於是又改成了生成隨機。)
經過多輪測試無誤之後,想著直接提交就能洗洗睡了,然後驚奇的發現根本就不會用什麽github。只好繼續求助百度,折騰了1,2個小時終於傳上去了
使用方法:http://www.open-open.com/lib/view/open1454507333214.html
本來覺得第二天寫個報告就可以美滋滋收工的時候,在第二天無意中發現好像要用CMD來測試,於是又去試了一下,完全沒法成功,不能接收參數,得自己再去輸入。。於是繼續頭疼了半天去求助大佬,後來還是群裏的大佬讓我去看一下argv,用來接收CMD傳遞來的參數的。於是又整了幾個小時搞定了參數接收的問題,但是改完之後就生成不出文檔了,之前覺得是前面的文件輸出寫入出了問題,整了半天發現除非我給定地址不然就各種找不到。最後還是群裏大佬建議我去管理員那個文件下面找找。然後想辦法把exe的當前地址弄出來,後面改成TXT.(後頭發現,如果直接開exe文件測試的話,確實就是寫在當前exe文件在的文件夾下面,不過換成cmd的話,當前文件位置。楞是在管理員文件裏面。)然後又經過了一大番鬥爭,總算是搞定了這個坑爹問題。
文件輸出:https://zhidao.baidu.com/question/326980647.html?qbl=relate_question_1
CMD傳遞參數:http://blog.csdn.net/FlyingBird_SXF/article/details/41843017
獲取文件地址:https://zhidao.baidu.com/question/535018091.html?qbl=relate_question_0
總的來說,這次實驗是真的學到可多東西(頭文件都多了好多好多個!理直氣壯臉),也感激之前大晚上還在幫我想辦法的各位大佬們。
附帶吐槽一下:寫代碼好說,改代碼。是真的煩。QAQ我們為啥要用那麽多奇怪的東西拉。明明直接點EXE就好了啊。委屈。
軟工實踐第二次作業-黃紫儀