零、准备工作
这次的作业仍然是结对编程，我们队伍的成员为：梁杰、夏天晗、谢祖三。上次我们是选择了一个时间大家聚在一起进行编程，效果不错，所以这次我们还是决定采用这种方式。由于大家平时比较忙，这周六日我又有事，所以最后决定周五晚上大家一起进行编程。
周五晚上吃完饭，我们就开始了讨论。
这次最大的一个改变就是语言。
上次我们使用的是Python，是因为我和夏天晗对Python比较熟悉，并且夏天晗的第2次作业比较好，所以决定使用Python。
这次作业，因为我们三个都选了一门Ruby课程，也都想挑战一下自己，所以我们决定使用Ruby来进行编写。
语言决定了，下面就是分工了。因为上次主要是我和夏天晗同学进行代码编写，谢祖三同学主要进行代码复审，所以这次我们决定换一下角色，由谢祖三同学担任主要部分的代码编写，我和夏天晗同学负责数据读入、结果输出、解法输出、代码复审等辅助工作。
分工之后，我们就正式开始了关于题目的讨论。
一、具体思路
第4次作业我们开始的时候并没有很好的思路，所以上周一直没有做。这周上课时候听了亚研院一位老师的方法，感觉有一些启发。老师的方法主要是深度优先搜索，我们决定在这个思路上进行思考。
难点1：深度优先搜索起始点的选择
深度优先搜索需要一个根节点，也就是起始点。我们认为起始点的选择是非常重要的，因为深度优先搜索需要进行回溯，所以节点的错误选择出现的越早，对性能的影响越大。也就是说如果根节点选错了，需要一直回溯到根节点才能继续寻找正确答案。而根节点的选择方法，经过我们的激烈讨论，觉得最好的方法就是随机选择。因为我们无法通过一些有效的办法来选择起始点，比如按照单词长度或者重复率等等，所以最终我们决定采用随机方法来选定根节点，达到平均效率最高。
难点2：深度优先搜索过程中下一步节点的选择
这个问题和第一个问题很相近，所以我们同样决定采用随机方法进行测试。
难点3：如何防止卡死
我们的搜索方法是结合随机和深搜的方法，所以可能会出现在一个小范围内一直循环的问题，也就是卡死。为了解决这种问题，我们采用了一种比较折衷的解决办法，就是当搜索在一定范围内循环次数超过阈值时，随机从矩阵中删除一些已有单词，来解除卡死。
难点4：如何判断结果是否正确
题目的要求很多，比如单词不能重复，四角必须有单词等等。当我们进行测试的时候，怎么判断结果是否正确成了一个大问题。为了解决这个问题，我们最终决定编写一个解题函数并用可视化的方法显示出来，这样就可以直观的判断是否满足要求。运行代码之后生成的solution.txt文件就是解法
二、实际编写
讨论出思路之后，我们就开始了实际编写代码。虽然之前思路和分工都已经很明确了，但是编写起来并不轻松，因为我们对Ruby都不算很熟悉，所以编写过程中经常遇到一些小问题。不过因为我们是一起编写的，所以一旦遇到问题大家就会马上讨论，三个臭皮匠顶个诸葛亮嘛！在我们的不断讨论和搜索之后问题往往都能被很快解决。上次编写代码时夏天晗同学的变量命名习惯并不是很好，这次有了明显的改变，代码可读性提高了很多。
三、测试功能
我们选择的测试方法是人工测试。因为我们编写了生成解法的函数，所以可以直接查看解法来判断是否正确。测试过程如下：
首先我们来运行一下程序，因为一开始并不知道矩阵大小，所以我们先尝试一下20x20（单词就不在这里列出了，可以查看allwords.txt文件）：
$ ruby homework04.rb allwords.txt 20x20
可以看到很快就运行出了结果，我们查看一下solution.txt：
可以看到满足了题目要求。
因为运行速度非常快，所以我们考虑可能20x20有点大，下面我们尝试一下16x16：
可以看到程序一直在尝试放置单词，但是有十几个单词一直放不进去，说明矩阵尺寸太小了。
再尝试一下17和18（这里不截图了，和上面的差不多），我们发现18x18的时候矩阵可以出结果，说明最小矩阵就是18x18了。
当然，矩阵并不一定要是nxn，你也可以使用nxm，如果矩阵的长宽无法放入最长的单词会提示出错。
四、总结
这是我们第二次结对编程，大家表现比上次好了很多，虽然使用了一个新语言，遇到很多问题，但是我们没有退缩，仍然完成了作业。
我们的作业经过测试，可以满足老师提出的要求：8方向，无重复，四角有单词，矩阵最小。我们甚至还编写了一个生成可视化解法的函数，让检测结果正确性变得非常简单。
五、时间统计
|
Personal Software Process Stages |
时间百分比(%) |
实际花费的时间 (分钟) |
原来估计的时间 (分钟) |
|
计划 |
10% | 18 | 12 |
|
· 估计这个任务需要多少时间，把工作细化并大致排序 |
10% | 18 | 12 |
|
开发 |
85% | 153 | 102 |
|
· 需求分析 (包括学习新技术) |
15% | 27 | 18 |
|
· 设计复审 (和同事审核设计文档) |
10% | 18 | 12 |
|
· 代码规范 (制定合适的规范) |
5% | 9 | 6 |
|
· 具体设计 |
10% | 18 | 12 |
|
· 具体编码 |
35% | 63 | 42 |
|
· 代码复审 |
5% | 9 | 6 |
|
· 测试（自我测试，修改代码，提交修改） |
5% | 9 | 6 |
|
总结报告 |
5% | 9 | 6 |
| 总计 | 100% | 总用时 180 |
总估计的用时 120 |