时间与人生——我的第一个开源产品经历

前言

前几天发布了 DiyFile v0.5.0 版本,算是做出了一个不算好看但基本能用的版本,今天就来聊一聊整个过程吧。

项目准备

为什么我想做它?

这个原因也很简单,当你学会一个新技术之后,把它用起来,最好的方法就是写一个项目。我也挺想开一个工作室,虽然不知道能不能走出这一步,但是为这个小梦想积累经验还是没问题的。

如何考虑技术选型?

需要学习的东西挺多的,先是画原型设计稿,最开始是用的 Adobe XD 画了一个简单的首页,然后基本上就照着这个设计了。最近简单自学了一下 Figma,后面做产品打算基于它来做了。其次就是项目架构的选型,大白话说就是用什么处理界面、用什么处理服务、用什么存放数据。最开始是用 Nuxt3 写了一版简单的,后来还是被我换成 Vite 项目了,只是没法做服务端渲染了,算是个小遗憾。前端的组件库选型,Arco-Design-Vue、Element Plus、Vuetify3、Naive 都用过,前前后后改了三版,才是现在所看到的样子(Vuetify3 + Naive 混用)。确实也踩了不少坑,浪费了不少时间,但收获挺大。

为什么这么说呢?因为接触了这么多组件库之后,我能在知道某个需求后,正确地选择组件使用了。不知道大家有没有思考过哈,现在让我们回到生产中的需求来。咱们先来想想,UI 原型图出来之后,前后端分别要做什么(分治)?前端根据设计,将 UI 组件分为层次结构,对应着前端每一个细小的组件。后端根据 UI,返回对应的 JSON 结构数据(当然也可能是其它的),咱们这里先不管数据怎么来的,那是业务细节,我们只需要知道,这时候 JSON 数据包含了 UI 原型图上要展示的数据内容。然后(合并),前端根据后端返回的 JSON 结构,映射到页面上的组件结构上,从而完成开发。

为什么说好的设计很重要,设计合理,那么 JSON 结构便合理,也就会自然而然的对应每个组件。UI 和数据模型具有相同的结构,哪怕分了很多层,很多个小组件,也一样能和数据结构中的一部分匹配。这样不仅节约时间(前端再也不用等后端搞完再写了),优秀的设计也能保证逻辑上的 Bug 更少。但是我们都知道,软件开发没有银弹,所以真正干活儿的时候,还是得变通,毕竟这也只是我的一点小想法。

话说回来,为啥我还是放弃 Nuxt3 了呢,虽然有很多插件还在预发布,或者在下个大版本才发布出来,毕竟没有的咱还能自己实现下。真正让我远离它的原因就是:“慢”。不是我故意要诋毁它,我是真没见过不管是启动还是热更新,都比 SpringBoot 2.x 还要慢几倍的东西,我真的越写越烦,再也不想碰这玩意儿了。于是我干脆把后端改成 SpringBoot 3 了,做成前后端分离架构。数据库这边,兼容了 MySQL 和 SQLite 。

总的来说,还是一个权衡取舍的问题吧,不过我选型还有一个要求,就是保证客户能够最大程度的白嫖部署使用。

项目开发

开发流程

开发的流程就比较自由,因为是自己一个人开发的,没那么多讲究。前端基于 Vitesse 来开发,后端就 SpringBoot 3 一把梭了。项目托管在 GitHub 上面,分为了前后端 2 个仓库。然后双分支开发,一个 main、一个 dev,根据实际情况打 Tag 并进行版本发布。

没啥特别好讲的,就聊聊开发中可能要注意的地方吧。前后端都用了代码检查,前端由于引入了 TypeScript,写起来会舒服一些。不过我基本上只解决报错,以及用 eslint 来约束代码风格,毕竟保持一致会减少阅读代码的障碍。后端代码的话,我很喜欢上语法糖,以及引入了阿里编码规约插件和 SonarLint,结合 idea 自带的扫描,基本上够用了,缺点就是很卡(我基本上蓝屏全是因为 idea😭。不过写 Java 代码的时候,我是非常喜欢消灭所有的黄色警告,尽量写的优雅一些,当然如果是大半夜写的状态不好,可能就。。。

代码写完后,就提交并 push 到 GitHub 了,有时候 git commit 我会使用 emoji,因为很好看。然后就会触发 GitHub Actions 来进行代码扫描了,这一步还是有必要的,比如后端会进行一次预构建,保证在切了一个新环境后,代码能正常构建(我碰到过本地成功,CI 失败的情况)。

然后就是自动部署了,review 后,测试也没问题,就可以合并了。

部署流程

部署流程也很方便,就第一次配置稍显麻烦。前端拿 Vercel 来举例子,它可以针对每一个分支和 commit 进行构建,构建完之后,会在 GitHub PR 页面显示 bot 发出来的预览链接,点进去就可以看到效果了。而后端的话,会由 GitHub Actions 自动构建镜像,然后集群内部更新镜像部署(这一步手动自动都可,开源项目可以考虑手动,防止恶意代码被 PR,然后在远程服务器上执行)。

重要的是配置反向代理,以及不同的前端环境,反代到不同的后端环境。数据库生产和测试可以偷懒用同一个,但是基于 PR 的(未合并),建议单独整一个,避免恶意代码执行导致脱裤,泄露 Key。

文档和社区维护

一个产品出来了,肯定得有一个文档,提供给用户查阅。在 DiyFile 发布后,我给它编写了一份文档 ,用户只要会使用部署所需的相关组件,应该是能够照着文档部署的,比如 Linux、Nginx 和 Docker。

社区维护就是比较难的,由于目前没有什么用户群体,也就没有去弄这个。只是在一些论坛发布了推广。

最后

经历了这个个产品后,我也大致了解了一款产品需要具备三大核心:好的创意、有人用、有人反馈。其它的很多东西,我认为都可以归类在这三个里面。没有好的创意,可能开发出来了就没人用,也就不会有人反馈了,支撑你做下去的动力也就越来越小。虽然一个项目生命周期的每一步都至关重要,设计、开发、发布、维护,但也都只是过程。

补充:

有了这次经历(虽然项目还有不少问题需要解决),我学到了很多东西,可能以后在做新项目时,会更加谨慎吧。接下来要沉淀一段时间学技术,为下一个产品做准备!也感谢你能看到这里,希望我的经历对你有所帮助!

updatedupdated2024-02-172024-02-17