答辩之殇

这些老学究们到底对什么样的答辩项目更感兴趣呢?


idea的夭折

炼丹机器学习要求凌驾于热门行业的创新点(本科预言家是吧),管理系统又认为没有含金量转而极其要求界面的美观(自己招标的教务系统不也丑得极具个性),本应体现唯性能论的项目却成为了面向普通用户设计的系统性软件(为什么有些优秀的分析器根本没有UI),使用当下主流的开发框架又被质疑如此平平无奇的信管系统是否需要那么多前后端框架提供支持(造不造轮子都没好话),同时数据库设计又变成了没有含金量的步骤(不做好设计被开除八百次都死有余辜),而代码量甚至也会成为评价指标之一(把框架源码也算进去行不行)······有些满含金点子的项目,很可能就在无情的毒打之中被扼杀在摇篮。

这些奇怪的建议真的能够为高校向社会输送人才的理念提供一点利好吗?

这些大部分早已与主流技术栈脱轨的老学究们真的能够拓展大学生的视野吗?

人人做研究,难道就一定会提高全国的研究水平吗?

当我们答辩时我们在干什么

这学期中在自己经历了三场课程项目答辩,有幸看过隔壁专业的毕业设计答辩,网上冲浪看到一些学生网友的答辩实录,以及参观了身处新兴一流高校的朋友的课程项目答辩后,我难以抑制自己产生上述的疑问。

在我看来,任何一套有助于提升开发者工作效率的开发框架都是其背后或个人或团队的技术与智慧的结晶,开发框架使大量的开发者不用关注大量操作系统底层与网络底层的实现细节,关注于业务功能的实现就好,然而在使用了开发框架后,你的项目很有可能就会变成“工作量不够”,而事实上,当我学通了计算机网络、操作系统,用几门程序语言硬是从底层造出了一个功能,写了上千行代码,得到的评价又会变成“这不都有现成的库吗?你自己写出来有什么新意呢?”。所以也可以说是学生们变聪明了,我们知道要想办法去做一些集合了一大堆功能的app,最好是一个网站服务,于是很自然地,学生们都想到了各种管理系统。

但久而久之,学生们也苦于老师们看腻了各种管理系统,于是项目的思路设计开始往热门的机器学习、模式识别,智能决策这些方面去靠,但是这类建立在大量学科基础知识上的应用又岂是我辈普普通通的本科生能够速成的,况且辛苦造出来的“轮子”也大概率比不上大厂造出来的“车”,那不如直接去找现成的模型或API集成到自己的平平无奇管理系统,于是评价又变为“你们的理解好像有点问题”或是“你们的数据集和模型是怎么来的?”这样暴露本质的问题。

看来不论是什么样的项目,哪怕是比得上一线互联网大厂的app产品,答辩上都会收到一些无趣、无理的问题。于是逐渐地,答辩就成为了一场如何把老师忽悠转的表演赛,用高级的话术、包装的语言,让评委老师认为这是及其有前景的项目,自己恨不得掏几百万出来投资入股,那你的表演就差不多到位了,成绩也就基本令人满意了。说来可笑,有点像是骗融资的,其实不假,毕竟有些高校工作者也是毕生追求科研经费呢。

所以,当我们答辩时我们在干什么?在最近的一场线上答辩,我们小组在从答辩开始到轮到我们组的两个多小时中,一边听着大会一边开着小会,进一步测试项目功能实现的同时盘点前面各小组项目得到的评价,以此来调整我们投屏演示时的话术,注意说话的细节,注意避开前面小组遇到的坑······很幸运,一路下来还算顺利,只是感到一点都不自在。

软件项目的答辩需要什么

仅在我看来,也仅从计算机相关专业来看,我所遇到的老师中,有很多都没有当下软件技术的工程经验,在很多专业相关的课程中,我几乎没有听到过任何与“公司”“工程”相关的词汇和字眼,我愿意相信他们并非不学无术,也许在学术研究与工程应用中间真的存在一堵很厚的高墙,这些老师能把理论理解得极为透彻,而他们对工程应用的理解或许还在十年之前,当我们用上新的程序语言、新的开发框架、新的UI组件,老师们就很难针对项目本身提出问题和建议了。当然,也有很多老师,相比之下他们就有明显的开发经验,至少这些老师敲起代码是十分熟练的。我们时常抱怨,如果是他们来带我们的课设就好了,但为什么不是呢?或许是他们的级别不够吧。

总有人说,计算机专业的核心是哪些亘古不变的计算机原理,以及形成一种计算机思维和素养,编程语言并不是第一要义。但事实上,程序代码的地位应当是计算机动态运行的一种静态体现,这是很重要的角色。作为高校鄙视链中的一员,我们对高职时常有一种理所当然的自信,但我们经常能够在一些比赛中名单中看到,这些来自“培训班”的创意往往出乎我们意料。如果说教授亘古不变的计算机原理是大学胜于高职的地方,那么实践项目的古板、陈旧就像开着一辆慢吞吞的老爷车在高速公路上,没有人会羡慕你的历史价值,别人只会嘲笑你跑得太慢。

纸上谈兵式的项目实践不应该是有志于成为开发者的我们的追求,经典的计算机理论不能永远通过古董项目来作为实操,反正即便是最新的开发技术也依然要靠学生自学,只是如果在教学指导上能够给出方向,那就业市场将感激不尽。

我在0919:随想 | Skycurtain.Dreamland中表示,只要讲座内容合理,我还是比较青睐这种讲座+项目的模式,而这种模式放在用于所有的计算机课程设计,也应当合理。

后记

2022-06-13

看到一个知乎问题:

如何评价领导要用代码行数衡量每个人的工作量?

有一个回答是这样:

用代码量来考核程序员,

相当于用油耗高低来评价汽车,但却以为油耗高的汽车好

相当于用煤气用量来评价厨师,认为谁用的煤气多,谁更努力(结果不做饭的时候,炉子也在燃烧)

相当于用药方里药的数量来评价医生,认为药开得多的医生,更努力(讽刺的是,医院真这么干)

相当于用“送一单外卖”所花的时间来评价外卖员,“人家送了十分钟,你却只送了三分钟,你凭什么少干七分钟活?”

相当于用作业量来评价老师,学生要是有做不完的作业,那这就是一位好老师


答辩之殇
https://skycurtain.github.io/2022/06/09/mourning-of-defense/
作者
Skycurtain
发布于
2022年6月9日
许可协议