³⁶

¹⁷

²⁸

"海底小纵队" 项目总结（伙伴匹配系统）

花萍雨

2025-11-24 10:02

阅读3726

花萍雨

2025-11-24 10:02

阅读 3726

想想该从何谈起哈，我想这个项目总结当中，我不会太去谈论关于这个项目的具体的某个实现之类的，那是笔记应该去做的事情，我想更多的去聊一聊在做这个项目期间我所收获的那些可以复用的内容，当然不只是因为这个项目，和我去逛编程导航的帖子有很大的关系（自己对于编程导航的开发还是太少了，宝藏有那么多，之前都没有意识到）但确实是在做这个项目期间发生的事情

1. 做完之后回头看

做完之后回头看的话，其实会和做用户中心时类似的一个感受，这个项目无论从业务逻辑上，还是具体的业务实现上来说都是极其清晰且简单的（但简单并不意味着容易哈），也大抵是因为做完之后回头看是一种全局视角，一种上帝视角；

而做项目的时候，其实是一种局部的视角，只缘身在此山中的视角，是无法做到一览众山小的，如果之后做的多了，我想鱼皮现在就可以做到这种程度了，或者架构师在没做项目之前单纯去看项目就已经是一个上帝视角了，还是很帅的！

2. 到底做了什么

这个项目的业务逻辑是很简单的，现在去复述一下的话，大抵就分为以下几个大的板块

和用户中心那一套是一样的，对密码和账号这些内容进行一个校验，逻辑通过的话，就可以正常登录 / 注册

用户

这个涉及的就是用户的个人信息，有哪些字段，比如基础的昵称，性别，邮箱，简介，头像啥的，在这个项目当中最关键的一个字段就是标签嘛，不像用户中心只需要一张表，因为标签的存在，是需要实现类似 Obsidian 里 "双向链表" 的一个效果的，后面根据标签搜索伙伴的时候会使用到，后面关于队伍板块当中的根据标签搜索队伍也是类似的实现，甚至可以说是一样的实现

因为这个项目当中是涉及到头像了嘛，其实用户中心当中也是有的，但是那时候我没做，总之就是要支持用户自定义上传图像的功能，是需要一个存储空间的嘛，我用的是阿里云，也算是把关于文件存储相关的配置给跑通了，后面再去做云图库的时候就可以当到云图库上面了吧

队伍

队伍的话，其实没什么，就是创建队伍，队伍的状态分为公开，私密，加密三种状态；队长拥有解散队伍，更改队伍信息，转让队长权限，邀请成员，踢出普通队员的功能；普通成员可以选择退出队伍；

这里加了一个队伍内的成员可以实时聊天的功能，一方面是实时，一方面是持久化，用到的技术就是 WebSocket + Stomp，不晓得鱼皮在这个项目当中有没有实现这个功能，因为我大部分其实是没有去看教程视频的

在确定要做哪些内容之后就自己去做了，不过想到这个点的时候还是挺高兴的，有种开窍的感觉，毕竟这个算是自己想到的嘛，然后也实现出来了，虽然这是一个正常人就很容易想到的功能，但还是很开心(^▽^)

这也是一个契机，去学习一项新技术的契机（虽然前面的缓存和并发什么的也是属于新技术，但确实没太往这边想），去沉淀下来一份关于快速入门一项新技术的 SOP，还是挺好用的，但在写 Demo 的时候也踩了一些坑

比如 WebSocket 的 Demo 我是直接在伙伴匹配系统当中去写的，一些配置上的问题就出现了，拦截器的问题也出现了...反正就是各种跑的不顺利，后来干脆新建一个项目来单独写这个 Demo 就顺利多了，所以这也是在快速入门一项新技术当中需要注意的一个点，这次我是真的记住了

也因此我打算在 GitHub 单独开一个新的仓库专门来放那些快速入门一项新技术的内容，一方面算是为后面做自媒体的在铺路吧，这种快速入门应该还是很适合去做那种 "两分钟教会你××" 的系列的，后面大概率会去做，但什么时候会去做，我打不了一个保票；另一方面 GitHub 是一个程序员的脸面嘛，有这个仓库也算是展现自我的一个部分吧

接着又给个人和个人之间也添加了这个消息的同步和持久化的功能，相比在队伍当中，一对一的实现会稍微难一点，但核心是一样的

性能优化

性能优化主要分为两个部分嘛，第一个部分是 Reids 缓存，第二个部分是并发，这里倒是太多想要说了的，去对比了有缓存，没缓存；有并发，没并发的一个性能上的区别，接着就是具体的实现

3. 一些可以复用的内容

3.1 上下文缺失的问题

这肯定是一个，直接解决我的心头大患，之前那期聊 Gemini 3 Pro 的文章是专门聊过的，在这里就不赘述了

https://www.codefather.cn/post/1991452355794612225

3.2 开发流程的规范

想法 -> 需求设计分析拆解 -> 设计分析前端页面，获得初版的 UI 交互页面（交付是图片） -> 后端 API 设计 -> 编写后端代码 -> 后端的单元测试 -> 编写前端代码 -> 前后端连接 / 全栈测试 -> 上传到 GitHub（方便之后的回溯）-> 直到完成所有的功能 -> 项目总结 -> GitHub 开源 -> 部署 -> 上线

这里的几乎每个环节，我都是有对应的专属于自己的提示词的，也是在做这个项目当中迭代出来的，迭代之后的版本在开发的过程舒服多了，但编程导航现在应该是没有上传 pdf 文件的功能吧，如果想要分享的话，篇幅太长了

3.3 Git

说到上传到 GitHub 上方便回溯，这次也是真的使用到了，因为新开了一个对话，导致上下文的欠缺（当时没没有解决上下文缺失的问题），生成的代码是各种的报错...前后端项目都乌烟瘴气的，就想到直接回溯到之前的版本吧，确实方便

还有关于 GitHub 的一点是，当拆解到最小功能实现的时候，每跑完一个后端 API 设计，单元测试，前端代码编写，测试之后，就上传到 GitHub 上。这样一方面是方便回溯，不至于说要回溯的时候，一回溯回溯到老久之前；另一方面是可以增加自己项目的真实性嘛

在昨天给项目的前端大更新的时候，我就忘记了这点，是在一波大改之后才去 Git 存档，这是之后做项目的过程务必要避免的

3.4 前端页面设计

虽然是一名后端开发，但未来是去做自己的产品的，就算不去做自己的产品，未来也是需要求职的，求职需要项目嘛，项目美观一些给人的体验相比不美观的体验差距我觉得不是一点半点的

就像做菜是讲究 "色香味俱全" 的，"色" 说的就是这道菜的视觉呈现，把 "色" 放到第一位是有原因的，我记得小时候看大耳朵图图的时候图图妈上一个烹饪班，还专门有对这个问题的讨论，印象还是挺深刻的（我确实喜欢吃，也喜欢自己琢磨吃，寒暑假的时候还是经常自己做饭的）

对应的产品设计上也是一样的，网站的话更专业的讲是叫做 UI 设计吧，虽然说肯定做不到像 UI 设计师的那种程度，但至少做到让人看到之后不要觉得这个页面很丑就行，也就是做到一个及格分吧，能加一些小设计就更好了

为了实现这一点，其实是可以通过在需求设计分析拆解之后，划分到尽可能的最小子单元之后，把自己的设计想法告诉 AI 来生成一个 UI 设计稿的，虽然绝大概率不能完全的实现，但至少是有了那么一个方向嘛，大抵是比不进行这个操作要好上一些的，而且这个操作其实也不怎么花时间，我打算之后大改前端页面之后的 UI 设计稿是下面这个样子的，最终的前端页面我会放到最下面，虽然说没有那么好看，但个人已经是很满意的了

3.5 对于代码和笔记的优化

先引用一下鱼皮对于代码的观点哈

对于学编程来说，千万不要去背代码！

本来编程知识这辈子都学不完了，背代码的话下辈子都学不完了。

学编程时，我们应该： 记住有什么，你能做什么，而不是具体怎么做 。

举个例子，现在让你‎设计一个电梯调度系统。你只需要听说⁠过有个东西叫电梯调度算法，以及它能实现电梯的有序调度就行了，而并؜不需要记住怎么写代码。等到要做的时候，去搜该算法具体的实现就行了。

再举个例子，现在前端的类库那么多，假设让你做一个网页动画效果，那你在此前只需要知道 Animate.css 库可以实现，等用的时候查文档就好了，并不需要把它的每个类、每种用法都记下来。别忘了，代码更新换代很快的，即使有的东西你能记住，但它也有时效性。

尤其是对于编‎程的初学者，不要去背代⁠码，你只需要知道某个函数大概能做什么事情，我؜要完成某个功能时能想到它（甚至是能搜到）就可以了。

看完这段，大彻大悟！我之前是真的会因为具体业务逻辑的代码实现记不住而难受的，现在好起来了，如释重负，于是花了大概三个小时的时间去重塑一下关于代码和笔记的内容，然后融入到了自己的开发流程，我不知道怎么去讲解我到底是怎么做的了，因为花了三个小时去做的内容，很难通过三言两语讲述出来，总之，最后沉淀下来的是几份 SOP

笔记也由原来的近乎的全盘整理变成了"记住有什么，你能做什么，而不是具体怎么做"

只记录能做什么？ 为什么选择这项技术做？ 其他技术不选择的原因是什么？ 路径和参数是什么？ 可能遇到的挑战有哪些？ 这些挑战如何可以通过什么解决的？

这些问题的对应的回答的就是下面的样子，我还加入检测文档，方便睡前复习，之前也会整理笔记，但是笔记太多了，就完全没有想要复习的欲望在，现在简单清晰了很少，还方便复习了，而且在采用这种方法之后，我的 Obsidian 就很难乱了，之前乱的原因也很好解释，就是我习惯把很多内容直接放到 Obsidian 里面，但是却不怎么整理，之前是全盘整理嘛，太反人性了，就...越积越多了，但现在不是了，在完成一个最小的功能之后，顺手就整理好了，心情愉悦~