项目地址：https://github.com/alvin0000/031702114
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| Estimate | 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 240 | 300 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 60 |
| Design Spec | 生成设计文档 | 0 | 0 |
| Design Review | 设计复审 | 20 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 20 |
| Design | 具体设计 | 20 | 60 |
| Coding | 具体编码 | 120 | 120 |
| Code Review | 代码复审 | 10 | 20 |
| Test | 测试（自我测试，修改代码，提交修改） | 120 | 40 |
| Reporting | 报告 | 60 | 60 |
| Test Repor | 测试报告 | 20 | 60 |
| Size Measurement | 计算工作量 | 20 | 60 |
| Postmortem&Process Improvement Plan | 事后总结, 并提出过程改进计划 | 60 | 60 |
| 合计 | 760 | 930 |
解题思路
首先在看到题目后，一般这种时常作为智力题的问题，它是肯定有一些不变的通性，在没有使用代码编程而仅由个人习惯、个人经验解题时常无意中使用了其中的通性。
在之前有做过这类型的数独题目，比如 HDU 1462 ，这种题规模不大，在有固定时间限制时也能很快运行完，而且在这次的运行时间并未严格限制，所以能用的方法有很多。
首先我想到的就是爆搜，这种方法常因时间限制被舍弃，或增加剪枝和启发式辅助，但在题目规模不大时，就很能看出它的好处，它思路简单，容易掌握，就算有bug也能很快的进行修改，在比赛时是很好的方法。
首先把数据存入数组，再加上对行、列、宫的标志数组，从头开始不断搜索和回溯，可以遍历到所有情况，当出现多解得情况只需保留搜索到的解，就能将所有的解找到。
独到之处：该方法对于小项目的时间耗费差距不大，但它能遍历所有的情况，解决多解问题，在极端情况下甚至在没有填数的地图中遍历出该游戏的所有情况。
设计实现
代码中总共用了一个类，五个函数，五个函数分别负责类的初始化、查找数字所属的宫、记录数据、遍历、输出结果，在记录数据与遍历时会用到查找数字所属的宫的函数
代码说明
声明类、和类里面所需要用到的变量
定义类的构造函数，初始化地图里的数据，和各数字使用情况
在各个阶级的宫的划分情况不同，需要计算不同阶级某一数字所属的宫
记录各行、列、宫的数字使用情况，方便后面遍历时选取数字
爆搜，搜索在当前数字填写情况下的所有情况，在错误的情况下回溯，在有解的情况下此算法必定能找到解
将数据输出到output.txt文件
主函数，从文件input.txt输入数据，并调用函数完成求解过程
心得体会
总体来说，这次的作业并不难，但还是很少用这种模式化的思考方式。之前解决问题的时候，所有的想法都在脑子里，并不会表现在文字上，但按照这种流程去完成一项任务，就感觉做的行云流水。
在构建之法的阅读中，也有很多值得注意甚至有意思的观点。比如思想误区的过早优化思想，把事情做在前面是我的习惯，虽说时间不够用时就无可奈何，但也会因为过早优化浪费很多的时间，