由於書本買到得比較遲，看的內容不太多，其中印象比較深刻的是第二章中提到的單元測試和效能分析。作為乙個好**，是要經過大量效能分析後的改進，提煉而成的，不能盲目地去改**，要通過效能分析工具測試後，得出**的各部分函式耗時資料，找出相對耗時較長的部分，進行優化演算法等，才是正確的**改進方法。單元測試部分，我目前在自己的ide中還無法實現...因此還不能說這部分功能有什麼用途，暫且記此作筆記，以後再好好琢磨
單元測試好壞的標準如下：
1.單元測試應該在最低功能/引數上驗證程式的正確性。
2.單元測試必須由最熟悉**的人（程式的作者）來寫
3.單元測試後，機器狀態保持不變
4.單元測試要快（乙個測試的執行時間是幾秒鐘，而不是幾分鐘）
5.單元測試應該產生可重複、一致的結果
6.獨立性——單元測試的執行/通過/失敗不依賴於別的測試，可以人為構造資料，以保持單元測試的獨立性
7.單元測試應該覆蓋所有**路徑（注意點：100%的**覆蓋率並不等同於100%的正確性！）
8.單元測試應該整合到自動測試的框架中
9.單元測試必須和產品**一起儲存和維護
personal software process stages
預估耗時（分鐘）
實際耗時（分鐘）
planning
計畫20
30· estimate
· 估計這個任務需要多少時間
2030
development
開發720
855· analysis
· 需求分析 (包括學習新技術)
120200
· design spec
· 生成設計文件
4020
· design review
· 設計複審 (和同事審核設計文件)500
· coding standard
· **規範 (為目前的開發制定合適的規範)
2020
· design
· 具體設計
3035
· coding
· 具體編碼
240360
· code review
· **複審
100100
· test
· 測試（自我測試，修改**，提交修改）
120120
reporting
報告180
190· test report
· 測試報告
5040
· size measurement
· 計算工作量
3030
· postmortem & process improvement plan
· 事後總結, 並提出過程改進計畫
100120
· all
· 合計
9201075
由於之前安裝過vs2015，使用過git，這兩個步驟可以跳過，然而vs2015的具體使用方法還不是很熟悉，在網上找了一篇比較適合新手的使用筆記。數獨問題，小時候有一段時間感興趣過，知道可以通過寫出9行1~9的數字，然後通過一定的行列變換來生成。於是我的演算法1.0就誕生了，通過隨機次數的行列變換來生成數獨，行列變換的原則是：交換只發生在前三行，中間三行，最後三行，前三列，中間三列以及最後三列之間，不能越界交換。興高采烈地完成了第一次嘗試之後，我測試了幾個資料。然而執行結果出現了兩個問題：1、數獨終盤重複率高，並且生成效率十分低...這一點是我還沒用效能分析工具就得出來的結論。。因為跑了半天才跳出來幾十個數獨終盤，用肉眼都感覺的出來這方法明顯不適合題目要求的大量資料...於是我也不打算push到github上了，直接刪了**重新寫（肉痛），看來只能用演算法來解決此問題了。演算法一直是我不擅長的部分，我思考了一陣，自己學過的遍歷方法只有可憐的bfs和dfs.....再結合題目，要生成乙個數獨終盤，應該要用一些數字去嘗試填進去，填到不符合的就要回到乙個特定點，重新嘗試填數字，結合演算法特點，認為dfs比較可能實現。然而，不符合的條件是什麼？返回到哪個結點？怎麼返回？我上網搜了相關資料，發現大部分的文章都提到了回溯法，大致思想跟我之前思考的方法是一樣的，但是展現了具體的回溯方法，回溯到的結點確認。即乙個點乙個點逐級向上回溯，例8行8列無法填入任何滿足的數字，就回溯到8行7列，重填，再無法滿足則返回8行6列，以此類推。而判斷方法就簡單了，避免行衝突，列衝突，格衝突。目前放在github**的就是演算法2.0 。
參考文章(
由於作業的要求不是很複雜，我分了兩個類
class todosudoku
畫了乙個很奇怪的流程圖...實在不太會畫，抱歉
再補個**大致思路。首先通過formatjudge()判斷命令列輸入引數格式是否正確，進入output()，output()中，若formatjudge()返回值為false則報錯，若返回true則繼續進行，通過shuf生成隨機測試陣列，通過shuf_first()生成包含題目要求的數獨首列，即首行首列為固定數值，進入fill()，fill()採用回溯法，通過numjudge()來判斷填入測試陣列是否正確，最後生成數獨終盤。
效能分析圖（1w的資料）
有圖得知，我的一大部分時間竟然是在toprint，輸出數獨函式上，目前想的方法就是用printf來替換cout會快一些。上網搜尋了資料，發現，最快的竟然是putchar()函式，原因是輸出字元是最高效的。第二耗時的部分就是fill()，也就是填充數字的部分。由於我演算法能力比較差...本身就是參考網上的方法，只能推測，在numjudge()中，可以省略一些步驟。在塊判斷中，我的原方法是，從當前塊中開始，逆順序乙個乙個塊往上判斷，這樣就會導致重複冗餘。例如在第一次時從第8塊開始往回判斷，第7塊和第6塊都是正確的，用標記標註，那麼第二次從第9塊開始往回判斷時，第7和第6塊就不用重複判斷了。這是目前的思路，但是**實現還沒完成。希望在接下來的努力中可以實現。
軟體工程實踐2017第二次作業
github鏈結 1 拿到題目後，覺得這題目和八皇后的題挺像的，都是行列衝突問題，因此覺得可以通過將乙個99的數獨圖變成9個33的圖，對每張33的圖進行數字的填充，例如先將1填入9張小圖中。按以上思路寫完程式後，在行數下移的同時還需要在對應的圖中找到下乙個數填入的位址，產生了可能會跳過某一行填入數值...
軟體工程實踐2017第二次作業
github連線 利用程式隨機構造出n個已解答的數獨棋盤 輸入 數獨棋盤題目個數n 0 n 1000000 輸出 隨機生成n個不重複的已解答完畢的數獨棋盤，並輸出到sudoku.txt中。參考 其實看了這個 以後，我深受影響，把自己的設想都推翻了，總覺得自己的方法不太好，想學習這個方法。我認真理解了...
軟體工程實踐2017第二次作業
預估耗時 分鐘 實際耗時 分鐘 planning 計畫20 10 estimate 估計這個任務需要多少時間 2010 development 開發375 465 analysis 需求分析 包括學習新技術 3030 design spec 生成設計文件 1010 design review 設計複...