分析程序的结构
1.第一次作业
度量分析：
类图
自我分析
主要是main函数处理了太多的东西，处理了基本所有的输入输出及其预处理导致比较臃肿。getOnePolynomial这是因为对正则的不熟悉，分隔多项式没有使用正则匹配而采用了原始的方法导致逻辑比较多
2.第二次作业
度量分析：
类图
自我分析
主要还是对正则的不熟练以及处理输入的方法不够优秀，导致我处理输入的部分总是过长，下面的第三次作业也一样。dispatch的operate方法是处理问题的核心部分，做了比较多的工作，导致逻辑过多
3.第三次作业
度量分析：
类图
自我分析
这两次作业框架基本一样，因此问题主要还是第二次作业的问题
自己程序的bug
第一次作业自己公测与互测都没有bug
第二次作业我代码中的一行的一个变量写错了，把处理后的字符串写成了输入的字符串，在互测中被报了两个bug。此外我只处理了楼层的0楼而忘记处理电梯的0楼不合法，导致了被报bug。我觉得第二次作业的主要问题是写完debug时覆盖的还是不够充分，对于错误树上的一些简单分支默认了自己没有bug，而事实上这部分还是出错了(bgm38)
第三次作业我吸取了第二次的教训，对所有情况都进行了分析，公测没有报bug。互测中被报了一个输出顺序的bug，这个bug其实我曾经发现过并试图解决了，但是可能我的解决方法还是有漏洞
分析别人的bug的方法
首先先看他公测通过情况，再测试几组自己写的比较强的数据，然后读代码理解逻辑，针对性找bug
如果公测有bug的话先去定位bug，一般这种bug周围的代码逻辑会有其他漏洞。之后我会看正则爆栈，数组下标越界这种便于找到的bug，而且找这种能直接crash的bug也显得十分合算。然后我让他的程序和我的程序对拍找不同，如果找不到的话就说明方法上肯定是没有什么大错误的，也代表着基本不可能再找出来什么bug了。后台对拍的同时我会去读他的代码，试图还原一下他的逻辑，针对性的找一下他的漏洞。不过我拿到的三份作业都是基本上一行注释都没有的作业，还原逻辑的过程也比较困难，最终还是主要靠对拍找bug
心得体会
制作一个计划表十分重要。要计划好时间，最晚周一晚上要基本写完，周二能运行并初步debug，留出整个周三找具体的bug，否则肯定是来不及debug的
自己写代码一定要写注释，否则debug时会忘记很多东西，而且也难以定位bug //当然在看了拿到的一行注释都没有的代码以后，在提交前我怀着复杂的心情删去了大部分注释(bgm38)
此外，做好设计在开始写十分重要，可以减少很多返工，避免用打补丁的方式解决bug
观摩别人的代码时要认真学习他的方法，学习优秀的部分，提升自己的水平
要多刷issue，多看微信群，及时更新对指导书的理解，避免重复踩坑