BUAA_OO_2020_Unit1 Summary

Homework 1

代码量度

BUAA_OO_2020_Unit1 Summary_第1张图片
BUAA_OO_2020_Unit1 Summary_第2张图片
UML 图

BUAA_OO_2020_Unit1 Summary_第3张图片

分析:

  • 第一次作业单纯的面向过程,只建了一个Term类,也是当作C中的一种struct用。鉴于不知道之后会有什么新的要求,加上对面向对象了解不够,并没有留任何扩展余地。

  • 因此各模块的复杂度较高,Term类的方法耦合度较高,第一次就飘红。
  • 关于优化,简单的把正项放在前面去优化,当然这过程中又引入了各种bug,不过也是因为对java各种语法基础知识以及容器不熟悉造成的。

  • 关于测评:感谢评论区大佬分享测评机思路,就模仿着建造了一个极其简陋的测评机,但也确实跑出了一些优化造成的bug。在互测阶段也解放了双手顺带炸了不少屋里的人(

    第一次的中测互测强测均未出现bug,优化也较为简单,轻松划过。


 

Homework 2

代码量度

 

BUAA_OO_2020_Unit1 Summary_第4张图片

UML 图

BUAA_OO_2020_Unit1 Summary_第5张图片

分析:

  • 我 必 重 构

    按照重构定律,第一次作业做的太绝的后果就是老老实实重构,其实想过要不要给第三次作业留余地,但鉴于能力有限(也可能是懒)而且第二次作业并没有空格位置的要求,索性破罐子破摔做好第三次重构的心理准备之后,想了用四元组做,确实省了不少事,但留下了不少隐患。本次作业有WF的要求,于是在排除了不合法字符后,打算用大正则套。此处感谢提醒判错不如判对及时把我从邪路上拉回来。

  • 本身用四元组做的目的是为了在第二次作业中获得尽可能多的性能分,但鉴于我又懒了(,于是在优化三角函数阶段只列举了一种情况,导致优化分惨不忍睹。

  • 关于测评:测评机进步解放人类解放双手。当然针对一些边缘的测试用例还是乖乖的自己试了试。

    第二次中测互测强测均未出现bug,除了优化炸裂之外,有惊无险的划过。


 

Homework 3

代码量度

BUAA_OO_2020_Unit1 Summary_第6张图片

BUAA_OO_2020_Unit1 Summary_第7张图片
UML 图

BUAA_OO_2020_Unit1 Summary_第8张图片

 

分析:

  • 虽然有了重构的心理准备,但是看到第三次作业还是倒吸了一口凉气。作业发下来后看了看题面就丢到一边了。因为上周末美赛压了一堆事加上心态炸裂就又推了一天。于是周三晚瞅了瞅写了个大致的cos、sin、pow、constant类就又扔一边了。周四火速开始搞,思路各种不对,问了一圈思路也没听懂什么东西,于是老老实实坐电脑前想递归到底是个什么东西、大正则不能用怎么办。磕磕绊绊写完之后开始思考WF怎么处理,又问了一圈,迷迷糊糊发现自己的逻辑好像不需要除了空白符之外的WF判断(盲目自信)。于是就此收手开始debug。大致思路如下:

    1. 对输入进行预处理,排除有限情况的空白字符WF后,就把空白字符扬了,将**替换为^便于拆分处理。

    2. 对输入通过不在()内的+-进行划分为项,再进一步通过*划分为因子,对因子进行相应的正则判断与递归处理。

  • 由于来回递归调用,我对飘红也只能无奈叹息。
  • 鉴于周五上午还在debug,我对优化几乎没有想法,因为受17级影响以为优化只占5%,但是忽然有人告诉我不优化按照我的写法优化分就为0了,在仔细询问了优化分占比20%后哭着开始优化了。优化之路极其艰难,鉴于用了递归很多东西没有好的办法处理,最后只在划分的时候与生成字符串的时候进行了优化,简单处理了一下就输出了。不过也好过原来令人窒息的长度。

    1. 在拆分项的时候,对项内各因子在求导前进行了合并化简。

    2. 在输出求导结果时进一步进行了各种罗列情况的化简。

    3. 总体来说还是要人脑考虑到种种情况,略繁琐。

  • 关于测评:首先在中测的时候出现了cos拼成con的错误de了半天,并在细节例如正负号的处理上纠结了不少时间,也废了不少提交次数,反思自己不应该因为时间不够滥用测评机。本来担心会不会爆栈或TLE或者其他错误,但我对自己的WF是极其自信的,没想到最后死在WF的判断上,忽略了三角函数的内部因子+ d中空格导致的WF判断,活过了互测,死在了强测的WF上。于是挂了一个点,低分飘过。

  • 至于发现别人的bug,还是交给测评机去做了。但事实上最后一次作业暴露出自制测评机的不足:

    1. 鉴于没有对0的次幂进行处理等情况,测评机自身就有部分问题

    1. 部分人的代码无法挂到测评机上,本来打算就此放弃hack,结果随便试了两个数就发现其错误,说明手动测评的针对性还是要高于自动测评。

    1. 测评机未对WF进行覆盖判断,覆盖面仍不足。

    大多数人的错误还是集中在优化过程中引入新的bug,例如化为0后前面少了*,或者直接化为空导致出现()的情况。

 


 

三次综合分析

  • 提前留下拓展迭代的余地的重要性。三次作业三次重构,虽然每次都针对作业的不同侧重点,但显然在开发项目中这种不留余地的思想是要不得的。

  • 面向对象思想的重要性。前两次作业完全没有体会到面向对象的思想,直到第三次才懵懵懂懂,明明在pre里都已经使用了面向对象的策略,但还是没有养成面向对象的习惯,须勤加练习

  • 讨论交流的重要性。显然闭门造车是要不得的,三次作业都与不同的小伙伴进行了分析交流,也收获了不少东西。特别夸赞一下评论区,有很多我正在苦苦思索搜寻的问题最后发现都能在评论区找到答案或者启发,感谢各位大佬的分享。

  • 实践化的重要性。按照自己的拖延症如果不写就能一直不写,虽然在第二次作业中,第一版被毙了重新写,但也算是对题意有了新的理解,如果迟迟不下手,空想的有效性对于我来说还是太低。

  • 学习新的东西的重要性。反思前两次没有为后来留余地的很大原因还是在于思想的懈怠不愿意去学习接受新的东西,除非逼不得已绝不学的思想须改

  • 思想的惰性要不得,三次作业中都出现了能用简单的方法解决就不去尝试新的或稍微复杂点的方法,也丧失了很多学习的机会。举一反三能力不够,之前学过的数据结构的知识不能应用到解题过程中。

 

 

 

 

你可能感兴趣的:(BUAA_OO_2020_Unit1 Summary)