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就好了啊。委屈。