以前的我,学了很多技术,做了很多项目,但是自己的核心竞争力是什么,总是有些模糊。感谢我的猿题库(和老板),给了我这么多复杂又富有挑战的需求和任务,我逐渐找到了答案:
把复杂的事情做简单,用最小最简单的理念把最大最复杂的世界规整起来,关注问题的本质,高效持续的解决问题。
趁着自己还记得住,用几句话记录一下猿题库曾经搞过的一些有意思的东西,省略了很多细节,不知道还有没有机会再补。
题目,考点,考纲,出题,练习
猿题库最核心的业务逻辑,题目,考点,考纲定制化高,出题复杂,练习复杂,嗯,猿题库的主业务在市场是几乎不存在有效的竞争对手,为了给友商添麻烦,里面的坑就不一一细说了。
题目做了最高级别的加密,通过某些技术手段,只能在我们认证的客户端访问,并且做了反抓取,还加了一些恶作剧,如果被系统识别你是爬虫,那么抓到的数据会随机生成不少错别字和错误答案,友商也请见谅,233。
客户端 架构
和大部分 app 一样,猿题库最早的时候使用的 MVC 架构。这个朴素的架构在早期发挥了他糙快猛的优良作用,但很快就把我们的 app 变得异常难维护。一个 VC 里面最长有 1k5 行代码,这对我来说是非常难以忍受的。
思考很久之后,秉承最小表现力原则,在尽可能不增加架构复杂度的基础上,心里默念没有什么问题是不能通过加一个中间件解决的思想,在原来的 MVC 架构上,增加了一些分层,使得各层的职责更明确,解耦更彻底:
M-S-DC-VC-VM-V Model:数据模型 Service(Agent,ModelDataController): 数据逻辑 DataController: 界面逻辑,和VC 一一对应 ViewController: 控件布局和一些胶水代码,和DC 一一对应。 ViewModel:控件展示 Model View: 控件
我认为,架构的目的首先在于统一,然后是效力。这个架构比起当时业界流传的各种新架构,最大的优势就是非常好理解,非常好实施,推广和切换的成本非常低。本质上来说这就是一个 MVC 的变种,没有双向绑定,没有不可控的第三方库,没有难以理解的概念。我在团队推广这个架构不到半年时间,就已经把项目里的大部分代码都切换到这个架构。从某B大厂新来的S同事看到我们的项目代码后,称感动到落泪。新来乍到的应届生也可以在非常