一 程序结构分析
第一单元可以被视为是OO的试水,几乎都是面向过程的编程,前两次几乎都是“一类到底”的形式,直到第三次才有了一个正式的数据分配的规划。
三次作业的类图如下(其中第三次更为复杂,所以分两张图来完成):
3次作业的度量情况分别如下:
前两次由于过于明晰,所以基本没有具体分析的价值。
第三次具体分析情况如下:
可以看见基本上复杂度集中于求导的方法。
接下来进行具体的总结。
首先前两次都可以看出来,完全就是一个类写到底,不写够500行绝对不罢休的那种。而且方法完全是按照流程顺序进行下去的,拿到源码的人可以很清楚的看懂每一步具体是什么。这里我就顺便说一下之前出现的代码风格问题,第一次我就出现了一个main写300行的情况(跟第一次客场测试的代码风格学坏了),然后仔细切割,才切出来十几个方法。
到了第三次之后,我才开始对方法和数据管理有一个比较明确的分类思路。
ChapterOne 和 ChapterTwo 这两个类分别是整个字符串预处理的全部方法和再一步处理的部分方法;DataTree就是存放小数据的三叉树结构,由于面向对象的便捷性,在树中也加了不少方法;Merger就是对三叉树进行回溯合并得出最终结果的过程,包括了如何批量合并加法分支,乘法分支和嵌套分支的情况。
不过这一次还是有个缺点,就是前两个类中只需要使用部分方法,被其他引用的时候,利用率很低。而且在中间判断树的最大深度,合并的时候,整个三叉树遍历次数过多,使得运行时间也比较长。
如上,在创建和合并计算的过程中,都要进行前序遍历。虽然
这几次下来,可以说还是在工程思路与数据管理上进步了很多。前两次写的可以说复用性很低,因为中间出现过各种各样的未考虑周全的地方。所以每到一次新的作业时,都要进行大部分的重构。
接下来就来讲讲自己所出现的一些bug
第一次的时候为了优化,强行去掉了所有0+和+0字符,然后强测直接先被炸了3个。也就是这一次,我就变得十分老实了,后面基本上就没再随便做过优化,顶多就是第二次做了同类项合并,第三次连合并都不合并了。
第二次出现的问题在于拆分每一项的时候,正则表达式稍微有点小错误,导致总是被别人炸这里
第三次出现的问题过于马虎,也是因为自己在预处理字符串瞎处理再处理回来所导致的…以及经常出现的利用单一字符分割字符串之后忘记判断最后的空串所导致的无法判断WF的情况,也被强测炸了一个点。总之还是小毛病不断,debug能力还有待提升,不能总面向评测机编程,主要还是要提高自己的眼力…
基本上出现bug的地方就是在正则判断的地方。这里只能说是仔细思考来避免问题了。
再接下来就是如何找别人的bug
说实话这个我找的不是很好…除了第一次分到了一个写状态机的勇士,我真的是仔仔细细认真的分析了其具体原理,找出了5个以上的问题。其他的我分别是通过盲炸和粗略地看代码来找出bug。然而到了第二次分到了A组之后,别人的bug我就一个都找不出来了,看代码看得也十分恶心。第三次就更没有找bug的欲望了(尤其是知道我自己的写出来是什么样子之后)。
不过在观看别人代码的时候,还是学到了不少东西的。比如说第一次,学到了动态数组的实用性,彻底摒弃大正则的判断方法。而到了第二次,主要是注重代码风格的学习,当然了,相当一部分的代码给我的感觉就是“为什么我的代码会和这么丑的代码放在一起”,当做吸取教训了。
比如说一些CheckStyle无法查出来的问题,拿中文拼音命名等等,实在是让我难以接受....
最后关于Applying Creational Pattern的问题
正如我说,前两次的复用性很低,直到最后一次才实现了真正的链式求导。在这一点上做的并不是很好。