前言
前几天发布了 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。
社区维护就是比较难的，由于目前没有什么用户群体，也就没有去弄这个。只是在一些论坛发布了推广。
最后
经历了这个个产品后，我也大致了解了一款产品需要具备三大核心：好的创意、有人用、有人反馈。其它的很多东西，我认为都可以归类在这三个里面。没有好的创意，可能开发出来了就没人用，也就不会有人反馈了，支撑你做下去的动力也就越来越小。虽然一个项目生命周期的每一步都至关重要，设计、开发、发布、维护，但也都只是过程。
补充：
有了这次经历（虽然项目还有不少问题需要解决），我学到了很多东西，可能以后在做新项目时，会更加谨慎吧。接下来要沉淀一段时间学技术，为下一个产品做准备！也感谢你能看到这里，希望我的经历对你有所帮助！