从「各种缩写我都知道!」切入,讲讲 Side Project 的前期工作

2021-10-04 by Aneureka

国庆期间趁着心情得以平静,我对未来几年进行了一次模糊的规划,也重新制定了短期的目标,其中有一项是「输入 ↦ 输出」。长期贫瘠的「输入 ↦ 输出」流会容易让人陷入自我怀疑和过分中立的泥潭,越发惰于感受世界,越发害怕发表观点。「输入」我们先避之不谈,对于「输出」的实践和探索,按照我近几年积累的惨痛经验——语言稚嫩不可怕,条理不够清晰也不要紧,怕在不能坚持。

因此,我定下了一个对自己而言有些狂妄的计划——月更。题材呢可以是最近读的一本书、重温好几遍的番剧、总结许久的游戏攻略,也可以是感兴趣的计算机原理、奇怪的小知识,还可以是我最近开始做或正在做的 Side Project,聊聊我对它的理解和思考,开发的过程,涉及的技术,等等。文章选题完全公开,并维护在 Writing Backlog,也欢迎大家在评论发表意见。

在此期间,我也会读更多的书,看更多的文章,消化更多的内容。希望在每次读与写之间,能真切感受到自己的进步,与大家进行更层次的交流。

积怨已久,或是灵光一现

Side Project 的想法来源于什么?大部分是积怨已久,但需要灵光一现来启动项目。比如大家可能会有类似的经历,在进入一个知识域相对孤立的环境(比如互联网公司)后,会被各种不明所以的缩写折磨,有些甚至很难在内网查到相应的解释,整个过程也很花时间和精力。因此,在「缩写」这个小领域,我想做个小机器人,帮大家答疑解惑,最终达到「各种缩写我都知道!」的美好愿景。

为什么是机器人?其实只是最近想了解做一个 IM 机器人大概需要哪些共性的步骤和实践。它可以是 TG 机器人,QQ 机器人,飞书机器人… 不过还是先从企业微信机器人开始做起。在良好的设计下,内核应该感知不到机器人的存在,换一种交互形式不影响共通的逻辑。

细化想法

有了一个模糊的想法后,我们就可以开始细化我们要做的事情了。

首先,从用户入手,系统应该至少涉及这两类用户:

  • 普通用户:查询缩写条目,对应机器人
  • 管理员:管理缩写条目,包括缩写条目的新增、修改和删除,对应管理后台

于是乎,我们有了一个最简单的交互模型:

abbr-bot.drawio

不难看到这个交互模型有一个致命的缺点,就是缩写条目的新增均由管理端完成。一方面管理员精力有限,缩写条目库扩大效率低,而这会影响到用户核心使用体验;另一方面,管理员知识涉猎有限,缩写条目分布不均匀,导致用户体验方差大。

因此,我们需要发挥群众的力量。群众的力量在哪里?

  • 用户缩写条目的查询记录,尤其是未命中的部分,为我们指明了扩充条目的方向
  • 用户可以分享 Ta 所知道的缩写条目,管理员负责审核

有了以上两点,我们可以开始优化交互模型。

abbr-bot.drawio (2)如此我们就可以寄希望于用户的爱心和分享欲,同时不需要漫无目的地补充缩写条目,而是优先解决用户查询过却未命中的部分了。

不过还存在一个问题,相对于查询,用户提交缩写条目的场景可能不足 1%,这也会导致缩写条目新增缓慢。换句话说,这个问题主要在于「管理员新增缩写条目」这个动作是低效的,管理员在新增缩写条目这件事上的时间占比越少,整体效率越高,理想的情况是管理员只负责缩写条目提交请求的审阅,而完全不需要手动新增缩写条目。

如果能在「用户查询」(占比 > 99%)的结果中增加对「用户新增」(占比 < 1%)的引导,事情会不会好很多?

abbr-bot.drawio (4)

就像这样,在用户查询成功后,从未命中的查询记录中选出几个缩写,引导用户分享 Ta 知道的内容。需要注意的是,这个过程会影响用户的查询体验,因此只在用户查询成功后加以引导,并且需要控制一定概率,比如 20%。这样用户自身就能形成缩写条目查询和新增的闭环,管理员只需要进行相对简单的审阅工作。

技术选型

Side Project 的技术选型我会偏向于激进,最好是把最近学习或感兴趣的技术和工具应用到项目中。技术了解和学习主要来源于最近读的书,看的网课,Github 上 star 的项目。比如「各种缩写我都知道!」会用到的技术主要是以下这些:

  • Framework:echo,基于 Go 语言的高性能 Web 框架,主要是之前一直用 gin,想做一些不一样的尝试
  • Deployment:docker,最近爱不释手
  • Debug:delve,最近接触的 Go debugger
  • Git:delta
  • CSS:Bulma, water.css
  • ORM:gorm
  • Database:PostgreSQL

然后就可以开始制定开发计划,设计数据模型,然后愉快地写代码啦!

今天这篇主要用「各种缩写我都知道!」举例,分享我在 Side Project 正式开发前的一些准备工作,这个流程可能会比写代码的时间长很多。以后有机会再讲讲关于开发计划、开发习惯、常用工具的一些实践,先这样啦。