黄道十二宫

前言

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

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

天秤座

先说说天秤座， 这是我维护了最久的一个项目，像对一个新生婴儿般呵护。项目从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 flask 开发过一个 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 Firebase Hosting 进行部署，简单高效。Vuepress 的确很有效的解决了