黄道十二宫

前言

这可不是什么希腊神话,更没有什么圣斗士,这只是我给我的项目起的名字而已,当然它也不叫黄道十二宫。

其实刚刚开始并没有这些名字,只是有一天,突然觉得我的后端项目有所寓意,叫做 天秤座 很好,由此一来,就有了其他星座的名称。目前一共是有六个模块,六大模块来组成这个完整的项目。分别有天秤座,水瓶座,处女座,摩羯座和一个还不知道要起什么名字的项目。

天秤座

先说说天秤座, 这是我维护了最久的一个项目,像对一个新生婴儿般呵护。项目从2017年就开始做,先后经历大约三个大版本,现在正在维护第三个版本。第一个版本是课程设计的时候,用 Java 和 Kotlin 混合写的,一个人写完了后台,当时前端第一次用 vue ,大家还是用两周的时间完成了项目,虽然简陋,很多东西都没有,但是已经有了项目雏形,基本解决了核心问题,这个只能叫做一个 DEOM。而后,利用寒假时间,和对象,舍友重构了整个前端和后台,重新对数据库进行了整理,这段时间过得很紧张,各种事情比较多,再加上过年,但是还是开学半个月左右完成了该项目的重写和重构,紧接着就是上线,这样就是 1.0.0 版本。这个版本无论是前端还是后端,相较于 DEMO 得完成度太高了,基本实现了所要的功能,但是有些功能有问题,在线代码评测,完成了一部分功能,加上服务器环境有问题,使得这部分功能被一直耽搁,直到开发下个版本的时候,才完成了该项目,也就是摩羯座,这是后话。

上线并不是一帆风顺的,出现了很多问题,当时服务器是在腾讯云上托管,买的基本是最低的配置吧, 单核两G1MB。第一天测试的时候,刚好赶上我下午有课,只能等下了课去看情况。一进实验室,老师就说:150个人同时无法进入,我让50个人先进,还是卡着进不去。心想,这种小水管,这么多人肯定加载不出网页来。随后在控制台上验证了我的猜想,除了出网流量满核,无论是内存还是CPU使用率都很稳定。随后添加到 5M , 为什么只添加怎么一点点,因为带宽实在太贵了。本来想着这下子应该可以了,用了一个压测工具,并发到了1000多才会出现连接失败,这下子应该没有问题了。然而事不遂人愿,50名同学同时访问的时候还是卡在哪里一动不动,心里很慌,因为不知道问题出现在哪里,感觉带宽不够。过了大概一到两分钟,才有几名同学的电脑上陆续出现了登录页面,慢慢的,大多数同学都打开了登录页面。心里总算是出了一口气,第一份试题同学们陆续提交,判题系统开始运作,判题系统是很快的,基本每个同学的答案都是秒出。但是也有问题,因为前端上有些地方体验不是很好,加上后端对这个没有进行处理,有些同学提交的答案不符合规范,此时就会出现:后端系统从消息队列里取数据,取到数据不符合规范,导致抛出异常,该数据获取失败,下次还是获取该数据,形成了一个死循环,导致后面提交的试题都积压在消息队列中。第一份试卷试题相对容易,对格式要求不是太高,偶尔有一两个手动处理一下就好。第二张试卷才是噩梦的开始。

第二张试卷的试题对格式有要求,可能是我在说要求的时候同学们没有听得很明白,导致了大批试卷格式错误,格式一错误就发生了上述情况。提交完试卷,老师就继续给他们讲课,而我只能用她讲课的这个空余时间修复这个BUG。一张两张手动还好处理,问题是我不知道有多少张,处理了一份又一份,这样手动处理已经不是办法了。当所有人都提交完试卷后,服务器停机,写了一个处理逻辑,基本就是检查该试卷是否符合规范,不符合直接 0 分。这样简单粗暴的处理方式,导致很多同学的分数为 0 分。于是乎又组织重新进行了一次考试。当然最后对这块的逻辑进行了重新调整,不会如此简单粗暴。在这里写这段话,永远没有当时感觉惊心动魄。

后续进行了很多测试,每次都会发现问题,需要及时的解决问题,只不过后边的问题也来越少。还有一次,对一个小小的逻辑进行了修改,使打分机制更加合理,心想这小小的逻辑应该不会有问题,没有测试代码,直接部署上线。悲剧的事情发生了,该题题型全部是0分。

此后进行了很多次考试,每次考试都会出现加载缓慢的情况,而我的理解也一直认为是带宽不足。直到服务器停机也一直认为是带宽不足。而在九月的某一天,我重新编译前端的时候,瞬间想明白了为什么加载缓慢。前端的 SPA 项目达到了 6MB 多,没有任何优化,每个人访问就要从服务器上去下载 6MB 的代码,怪不得缓慢。因为是第一次使用 SPA 并不知道性能上和体积上的优化,吃了大亏。

天秤座指的是这个后端项目,和前端 vue 并没有多大关系。到了 1.0.0 的项目,完全使用了 kotlin 。到了目前维护的 2.0.0 的项目,依旧是 100% kotlin。kotlin 这个语言是我目前为止最喜欢的语言,没有之一。官方宣称的 100% 的兼容java 也使我尝到了甜头,在不改变原来的生态,框架的基础上,使用了新的语言,不仅仅是简化了繁琐的Java,而且比java更加现代化,了解了一些java没有的语言特性等。

在学习 kotlin 的过程中,个人感觉,语法其实很重要,语言特性很重要,掌握一个语言的语言特性,才能更加的写出地道的代码,就好比如说一口地道的英文一般。而且今天的kotlin,也今非昔比,很多人还认为 kotlin 仅仅是 java 的语法糖。过去一周,尝试了一下 kotlin native,以我猜测,估计过不了多久,官网上就会写出 100% 兼容C/C++ ,虽然个人对 C/C++至只剩少,但是通过体验来说,基本可以实现,而且这应该也是 kotlin 团队的愿景,毕竟目前是能寄人篱下。

水瓶座

先讲一个笑话

Angular是两个框架。

前面说到了 SPA 加载缓慢等问题,因为写前端的同学找到了工作,没有时间去维护这套代码。还有一个原因就是当时写的时候时间紧张,功能实现为主,结构,代码混乱,技术债欠的太多,与其去还技术债,不如另起炉灶,重写前端项目。这便是水瓶座的由来。

经过对比了一下前端技术,选择了 Angular 作为开发。相较于其他两个技术来说,Typescript 的完美支持,依赖注入和Rxjs这些后端常常使用的技术等,由此选择了 Angular。当然也有一些缺点,学习曲线陡峭,并不像 vue 一般简单。

水瓶座基本是对上个版本的重写,但是界面设计基本和上个版本一致,将上个版本中用户体验很差的填空题答题部分进行了完善,完成了答题卡功能(上个版本也有这个功能,只是一直有一个bug)。经过了上个版本对单页应用的简单了解,这次非常注意应用体积,虽说 Angular 的打包体积本来就要比其他两个体积要大(Angular 7,日后版本开启 lvy 之后应该体积是差不多的),基本所有的路由都启用了懒加载,而且还注意体积优化,再也不会像之前那样,做一个那么大体积的应用了。水瓶座目前正在经历从零到一的过程,这个过程相对痛苦,但是一旦完成也是最有成就感的阶段。

其实有时候会想 是不是选错了技术栈, react的生态可要比Angular丰富的多,但是有时候也会想Angular真的好厉害,基本把你需要的东西都考虑了,开箱即用。cli 如一把神兵利器,太强了,可能是我见识短,这是我目前讲过最强cli。对于这次技术栈选择,并没有将 vue 考虑进来,并不是说 vue 不够优秀,而是对 Typescript 支持不够好,为什么非要用 TypeScript 呢?说白了还是类型问题。之前用 python flansk 开发过一个 web 基本算是试水,发现编写速度的确快,但是 debug 的确痛苦,没有完善的类型提示,很多不必要的错误只有在运行的时候才会发现,后来 vue 的版本, js 也在类型上没有严格的定义,所以在技术选型上,必须有完善的类型检查机制。曾经也试想过用 kotlin react 作为开发,看了一下官方支持,基本常用的库都有了 kotlin 版本,唯独缺少的就是一个 ui 库。其实在团队技术选型上要做好多考虑,组内是否可以快速转变,是否愿意逃离舒适区,新的技术栈性能怎么样,生态怎么样,日后更新维护怎么样,官方支持怎么样?等等一系列问题。每做一个决定就是要对所有人负责。还好,我只要对女盆友负责就可以,毕竟这个团队就两个人。

我们都是学生,没有舒适区,也不喜欢舒适区,喜欢尝鲜。就目前三大框架来说,react无疑是生态最好的一个,但是我没有选他。而官方的维护和日后更新也是关注的一个重点。现在的 Angular 来说,基本会在 谷歌内部的 600 多个项目上先行使用。有着 谷歌爸爸的支持,虽然可能在坑一次。。。

总体来说,直到目前 Angular 给我带来的惊喜多余惊吓。

摩羯座

摩羯座可大有来头,这个项目花了我三天的时间。

之前学院里是大一上学期开设c语言,下学期开设 面向对象(Java),大二上学期开设 数据结构(C语言描述)。这样的排课其实有问题,要不然就把数据结构放到c语言后面,要不然数据结构就用java语言描述的版本。遮掩的课程不知道已经用了多少年了,就在今年将采用大一下学期数据结构。

所以,要改判题系统中的代码题判题规则,数据结构基本都是算法题,所以我的要求也是按照 oj 系统的算法测评机规则来做。基本对输入数据和输出数据进行判断,而且要求不能超时,不能去破坏系统等。

写这个第一时间想到是 C 语言去写,因为相对于其他语言来说,C语言更加的底层,更好的控制一些条件。但是也有一些问题,C 语言非跨平,也就是意味着相同的功能既要在Windows下写一遍,Linux写一套,无疑增加了成本,而且尝试使用了C语言进行编写后,发现C语言的接口晦涩难懂,不是很好理解。经过短暂的尝试,放弃了C语言,转而投向了Kotlin,前面说过,kotlin已经向Native方向发展,所以个人感觉使用 kotlin native 也是一个不错的选择。然而使用 kotlin native 却发现和c语言一样的问题,他并没有去自己实现一些接口,而是直接使用了C语言的接口,同样也是没有研究明白。

就这样耽搁了两三天,一直没有进展。

偶尔一天,看到了一篇关于java调用go语言的博文,将go写的应用打包为动态库,然后通过 jni 调用。就这样边学边写,用了大约三天的时间,基本写出了windows平台下的测评机,因为在windows下和linux下所执行的脚本命令不同,所以要适当的判断一下操作系统。 Go 语言写起来还是很轻松的,也很方便的调用系统底层。

处女座

处女座是一个有意思的项目,它本不在计划中,只是项目需要写文档,(其实我是不喜欢写文档的) ,于是乎看到了 vuepress 这个项目。正好使用这个项目快速写文档。vuepress上手很简单,只要通过简单的配置就可以写文档,而且通过 GitHub page 进行部署,简单高效。

不介意的话,可以请我喝杯咖啡吗?或扫一扫支付宝领红包