BUAA-OO-U4-大宗师

​ 夫天地者,万物之逆旅也;光阴者,百代之过客也。而浮生若梦,为欢几何?古人秉烛夜游,良有以也。况阳春召我以烟景,大块假我以文章。会桃花之芳园,序天伦之乐事。群季俊秀,皆为惠连;吾人咏歌,独惭康乐。幽赏未已,高谈转清。开琼筵以坐花,飞羽觞而醉月。不有佳咏,何伸雅怀?如诗不成,罚依金谷酒数。

​ —— 李白《春夜宴从弟桃花园序》

一、第四单元总结

1.1 总论

​ 这个单元最大的主题其实跟第三单元是一样的,就是怎么糊弄怎么来。第三单元是因为操作系统的压力,第四单元因为是烤漆,所以多有糊弄,也是没有办法的事情。除了烤漆压力外,其实题设方面也是给足了糊弄的空间,主要有以下几个方面:

  • 题目设计上完全脱离了整体架构,用接口约束改成了一道道的算法题。
  • 去掉了互测,所以是没有人绞尽脑汁搞别人的。
  • 不再卡 TLE,所以算法的需求就变成了要跑得稳,而不是跑得快。
  • 博客要求也减少了,要不我怎么敢随便胡咧咧。

​ 但是是不是糊弄就不好了,我觉得肯定不是的,很多时候,糊弄也要有糊弄的手法,没人要求自己的 1000m 跑得要跟博尔特一样快,即使是自己的最佳状态。更何况不是每个人都喜欢跑步,都愿意跑出好成绩,糊弄才是人们做事情的常态。我个人理解的是,我们既要学习如何把一件事情做到精益求精,也要学习如何糊弄而且还能弄得差不多。而且尤其是做团队合作,本来就不能控制和要求别人去全心全意的投入,所以学会糊弄不仅是自己的事情,更是合作的事情。

​ 接下来讲几个糊弄的要点,都是我认真踩过坑以后总结出来的,大致上是十分有用的。

1.2 知识与题目

​ 这个单元名义上是 UML 解析器,然后我和身边的小伙伴就去看指导书了,看完指导书还不够,还要看课程组提供的手册,在看完如此晦涩的手册后,还要意犹未尽地看官方的手册。然后这些都看完,结果一做题,发现根本不沾边。

​ 那么我们来分析一下这个错误哈,这个错误可以归结为“我对于第四单元太重视了,我要好好弄”这种自我陶醉的理由。不过其实呢?我觉得程序开发最重要的就是面向需求开发,那么到底什么是需求,需求有什么特点。那么其实可以分析一下:这个单元的背景是 UML 官方文档,然后的背景是出题人是一组人。这种背景最容易推导出来的结论就是:每个人都会对官方文档有自己的看法,他们甚至不能将一个人对于官方文档的理解出成题目,最后的题目的逻辑肯定是极其简单的,简单到让所有人没法质疑。

​ 换句话说,这个单元的开发任务就不再是“结合 UML 知识做题”,而变成了“结合出题人搭建的框架做题”。那么显然死扣知识就变得没意思了,因为本来需求就不是知识,而是出题人搭建的模型。

​ 我已经学了一个学期的面向对象了,居然这点没有考虑到,可谓是基本功不扎实啊。

1.3 官方包与读代码

​ 那么确定了第一点以后,那么糊弄的解法就出来了,只看指导书和官方包,可以最快的理解出题人的模型。然后就会遇到另一个坑点。就是这回的官方包是一个冗余的包,它不仅可以用来解析标准的输入内容,它好像还可以直接解析 .mdj 文件,然后还会有一些其他的功能,这就导致这个包里真的是,啥东西都有。有的时候费劲马哈的看完一个文件,然后一看,真的是没啥用。

​ 关于这点,我到觉得是自己的问题,毕竟以后很大概率都不能自己掌握全局,很多时候都是面对一个大项目,自己耳聋眼瞎就得写代码了。这种问题我之前也想过,然后从理智中推导出几种方法来:

  • 顺着调用顺序看,比如从输入函数开始看,看输入的东西变成啥了(一般都变成比较容易管理的数据结构了),然后看这些新的东西又经过怎样的处理变成输出了。
  • 按照数据结构的组织顺序看,比如先看一个管理其他数据结构的内部,然后看它管理的东西的结构,这样一级一级,一个 BFS 就看完。
  • 按照题目的要求看,比如从一开始的 UMLElement 看,然后一步一步的,巴拉巴拉
  • 按照包的含义看,不同的包体现了不同的逻辑思维,然后一个包下的事物一般具有某些相似性,可以很有逻辑的看出来。

​ 然后当我逐个应用的时候,发现虽然确实自我感觉很好,觉得自己是在像一个有逻辑的人一样看代码。但是真的好慢,这些策略不是在帮我提高看代码的效率,而是在帮我特别慢的看代码速度下不着急的。

​ 幸亏之前在 U3 的时候就犯过这些错误了,到 U4 的时候我改成了“通篇浏览 + 跟人聊天”的方式。真的是超级快。首先通篇浏览一下整个项目的结构,不用看得很细,但是最好要有笔来记录一下,然后记录完成以后就去找已经完成的人聊天,不用聊框架之类虚的东西,就直接问他怎么求解,然后聊几句大致就可以明白出题人的思路了,然后就开始实现就好了,实现的过程中不断的去矫正,基本上就没有问题。

​ 为什么这种方法更好呢?我个人觉得是因为人们理解一个东西,其实是把各种信息在脑子中抽象出一个结构来。然后上面旧的方法就是整个将整个结构全都理解了(他们顶多算是优化了理解的速度),然后再开始动笔。但是新的方法则是需求推动的,接近于语言或者新生儿探究世界的方式,是一种顺序化的,逐步的输入,难度梯度比较平缓,所以更加容易。

1.4 评测

​ 不出意料,又要搭建评测机了,同时又不出意料,我又搭不出来。不过经过了一个学期的打磨,我已经准备好了一套应对办法。首先,手里拿住一个最好的自动化器,然后为其名曰“合作”,骗到一个贼好用的数据生成器,然后基本上普通测试就搞定了,然后再建一个特殊样例的提交平台(不用实际建,就是到处跟别人说有好样例发给我呀,我这里有一大堆好样例,大家共享啊),这样基本上强一点的数据就搞定了。

​ 这中间一定要就事论事,具体问题具体分析。比如面对大佬,可能资源的共享的诱惑力就没有这么大,因为大佬永远都握有资源,这个时候就需要抱大腿,乌漆嘛黑,天昏地暗地舔就完事了。对于同为菜鸡的同学,就一定要认真负责,一定要勇于分享,一定要积极检讨,一定要把评测机的难度一降再降。这样才能团结群众,充分发挥群众的力量。

1.5 算法实现

​ 这个坑经过第三单元的训练,我这回是一点也没有踩。很多时候,算法不是复杂度越低就越好的,因为越低的算法复杂度,一般就意味着越高的空间复杂度和实现难度,就意味着很难拓展(因为很多算法的提高都利用了具体问题具体分析的办法)。

​ 不过这回因为官方放海了,所以只要意识到“不会卡时间”这一个点,那么就可以很好的解决问题了。

1.6 架构设计

​ 其实于哥哥在讨论区已经说得很清楚了,主要是将三种图的功能分别拆到三个类中去实现,可以有效的避免 500 行的限制。但是我看见有的人对于每个 Element ,都自己实现了一个类,那么就显得有些冗余。其实有的时候,为了实现的更快捷一些,可以考虑一些摆烂的方法,比如对于 Endpoint 可以和 Lifeline 当成一个类,InitState, State, FinalState 可以是一个类。其实这样是我在第一单元,一定不会开心的,因为这是展示继承和多态的大好机会。但是怎么说呢,我已经不是一个哪里哪里都要用面向对象来解决的菜鸟了。我觉得很多时候不是“好”最重要,而是“适合”最重要。


二、OO 课程总结

2.1 傲慢与偏见

​ 必须承认,我在学这么课程之前就已经有了很多的其他东西。当我听到“设计模式,需求分析,博客,架构”的时候,勾起了很多我的年少轻狂。因为这门课程很多时候都是在讨论概念,讨论设计,讨论架构,讨论分类,讨论信仰。可能这对很多同学来说是很好的事情,因为可能是第一次接触,而且大家都年轻气盛,又有几人不想挥斥方遒,指点江山,乘风破浪呢?我看到很多人沉迷于架构设计,沉迷于评测机,沉迷于论道,沉迷于刀人。真的,客观的说,OO 一定是最受六系学生欢迎的课程,无论大家学得好不好,最后的博客感想都是十分感人的。

​ 可能只有我是一个异类吧,上面说的这些东西,在我很小的时候就接触到了。我小时候是美术生,从小就是在各种架构设计中度过,每天就是琢磨出甲方的需求和怎么应付甲方。之后就是当生竞生,每天沉迷于动物分类,植物分类,对于人类尝试给毫无因果的东西分出类这种事情习以为常,每天就是写总结。

​ 反正这就导致我对于很多事情没有那股子新鲜劲儿,反而对于很多事情无聊的一面深有体会。所以很多时候面对课程,是有很大的傲慢与偏见的。尤其是我早年的经历并没有完成,当美术生当了半截子,当生竞生也是没有登峰造极,导致我对于很多问题的思考全都停留在愤世嫉俗的地步,没有更进一步学会和解。

​ 所以我个人总结是,OO 可对于我不是尝鲜的课,而是一个去解决自己的傲慢与偏见的课。

2.2 大宗师

​ “大宗师”是我最大的体验,有的时候,不是“穷人力”即可以达到的。可以看下面这句话

泉涸,鱼相与处于陆,相呴以湿,相濡以沫,不如相忘于江湖。与其誉尧而非桀也,不如两忘而化其道。

​ 好了,装逼的话说完了(其实我也不知道这些话啥意思),我觉得最大的领悟就是我们的设计目标不永远是“最好”,或者永远不是最好。很多时候,程序开发是一个权衡的东西,在程序内部,时间要和空间权衡,可迭代性要和实现难度权衡,架构设计要和具体实现权衡,面向对象要和面向过程权衡。当一个方面变得更好,必然会有一个方面变得更差。

​ 我没学这门课之前,脑子里想的都是为什么不能更好了,比如画画的时候,明明起稿的铅笔软一点,效果会更好,或者学生物的时候,在某些分类上,放弃一些传统的标准去做分类,会有更好的效果。这就导致我在画画的时候,谁都不服,就服分数,学分类学的时候,谁都不服,就服 DNA 相似度分类。但是其实呢?很多时候是没有一个固定标准的。

​ 比如第一单元,既然没有卡时间,那么自然不用考虑什么样的顺序可以化简的更短,直接暴力的每个都尝试一遍就好了。我的第一单元,醉心于架构的优雅,而输在了不肯接受实现的丑陋。

​ 再比如第二单元,在明明知道没有办法优化性能的前提下,执意优化性能,在知道标准模式很好的时候,却非得探究多线程与面向对象的冲突,输在了沉迷于自己学习的幻想中无法自拔。

​ 再比如第三单元,在明明知道时间紧,任务重的情况下,依然认真完成任务,而且完全是一种自我感动式的完成,对于真正的时间的复杂度的需求视而不见,沉迷于 JML 的数学形式和跟人辩论中无法自拔。

​ 其实只有第四单元是好的,在这个单元里,虽然我没有做出想第一单元那么优美的架构设计,也没有第二单元那疯魔成活的调度优化,也没有第三单元纵观全局。但是它很自然,虽然丑陋,但是自然,是符合“大宗师”理念的。

​ 回顾下来,虽然课程让我开心的事情有很多,但是最让我骄傲的,就是完后了第四单元,因为从这个单元开始,我从一个幼稚的人,向着一个成熟的人迈进。

2.3 对象

​ 那么到最后,我解决了吗?

​ 其实没有,很多时候不是道理想通了,事情就办成了这么简单。我无论比别人在认识上面多走了多少,在很多时候还是不如别人。哪怕不与别人相比,与我自己相比,也是这样,你说我想出了新的道理了吗?想出来了,做出新的改变了吗?做出来了。但是真的有多少进步吗,没有。

​ 其实就是两手空空,毫无所依而已。不过其实事情大部分都这样。我听过一个故事,大致就是讲一个小男孩拿着一个曲别针,先用曲别针换了饮料,又用饮料换了帽子,反正最后经过一系列的价值不等的交换,最后换到一个别墅。我小时候就想,这故事不具有美感,最好这个小孩再用别墅换回曲别针,或者一个小姑娘的笑容,这样在别人都为他丢失一栋别墅而烦恼的时候,酷酷的留下一句“嗨,反正不过损失一个曲别针”。

​ 在我敲完了这四千多字的博客的时候,我对于 OO 的看法尘埃落定,这课是好课,我来的时候连曲别针都没有,我走的时候却认识了很多朋友,发生了很多故事。

​ 最关键的,这门课程叫做“面向对象”,哪怕强如杰哥,兼具“得意门生,最佳性能,最狠狼人,暖心分享”四项大奖,他也有很大的不足,那就是他没对象啊。我就算各种强测各种寄,各种互测各种被刀,各种装逼各种被打脸,各种坑全都踩了一个遍。但是我在课程学习的过程中,真正做到了“面向对象”啊,我的代码都是“面向对象”编写的,我对象就坐我对面。这,你说说,有什么办法呢?强烈建议课程组给我这种贯彻课程基本精神的人满分以滋嘉奖。

​ 最后我想说:

我跟 OO 有过对象般的争吵,我也希望和对象有 OO 似的美好。

2.3 尾声

​ 一气呵成之后看了看要求,发现没有提意见,我真觉得 OO 绝世好课,故提一下建议:

  • 可以考虑优化指导书的渲染系统,个人感觉做的还可以更漂亮,尤其是斜体和数学公式。
  • U3 或者 U4 开放一些架构设计的部分,连着两个单元没有架构设计,有点怀念。
  • 研讨课可以考虑不加分,这样大家的分享会比较理想。身边有很多不太擅长演讲的人为了这个很难过。
    最后,诚挚感谢吴际老师的教诲,战晨曦,吴家焱等助教的指导,冰哥亲人般的关怀,jjj, lsz, zkg, wxz,wxg, cjj, ghy, cnx 等人的帮助。爱你们。
posted @ 2022-06-28 19:58  Thysrael  阅读(49)  评论(0编辑  收藏  举报