KUN's Blog维护与扩展
对于绝大部分的项目来说，花在维护上的时间和精力都是比花在开发和设计上的时间要长的
我们的项目也不例外，花在维护和扩展上的时间将会远远大于开发时间。
我们在开发之初就充分考虑了项目的可扩展性，在代码编写和 UI 设计上都有讲究
维护
恶意注册
我们暂时是没有临时邮箱验证的，因为考虑到有的朋友注重隐私，偏好使用自己的域名邮箱，又或者对邮箱的隐私有担心，所以我们不禁止临时邮箱
这意味着我们需要格外注意用户注册的频率，防止恶意注册
目前我们对于注册的限制仅在不同邮箱和不同 IP，这对于真正想要恶意注册的人群可能收效深微
spam 检查
我们的文本也没有过滤，这意味着我们也需要定时查看用户的发言，避免不萌萌的讨论
这里说明一下，并不是我们想要约束，而是，这是一个 Galgame 论坛，我们希望它被塑造成 Galgame 的样子，因此，其他的交流就显得不合适了
例如，手游，职场，生活，家庭，工作，考公考研，出国，交际，这会导致环境变成别的样子。因此，我们在首页加载时永远只呈现 Galgame 相关（部分公告除外，之后会有专门的页面）
还有其他的内容，例如广告，政治，黑产，R18-G，自我否定，人身攻击，这些永远都萌不起来的话题，不可以出现在世界上最萌的 Galgame 论坛
当然，我们不会明令禁止这些，我们会默默的删除这些萌不起来的内容
BUG 修复
截至目前，我们已经内测了将近两个月了，过于明显的 BUG 已经全部修复完毕（总共可能有几十个）
如果发现了任何的 BUG，可以直接联系我们，我们提供了极为方便的联系渠道
运行异常
一个系统是会出现异常的，我们目前没有系统日志，之后的重构项目中会存在，目前需要做的是定时查看并备份数据库，做到用户数据的完整和可靠
扩展
新功能开发
本项目在开发之初就充分考虑到了可扩展性，这在本项目的前后端都有体现
前端我们采用了组件的方式，组件化编码本来就有良好的可扩展性，在此基础上，我们还做到了这些
- 统一的 API 管理，API 请求全部集中在
src/api和src/hooks文件夹下 - 统一的错误处理，错误处理集中在
src/error文件夹下 - 统一的 store，store 全部在
src/store文件夹下
在这些内容的基础上，我们还保证了代码被拆分的非常简洁，非常易于理解和扩展，这也和我们使用了 <script setup> 的简洁写法有关
我们的 src/views 文件夹下的每一个文件夹就是一个单独的页面，想要开发任何的新功能可以直接在这个文件夹内新建组件
举例，如果想要给前端新加一个非请求的功能，可以这么做
- 直接在对应的文件夹下新建组件（一般在该文件夹下面的 components，如果没有，可以新建）
- 编写 Vue 代码
- 引入该组件
要增加一个带有请求的功能，可以这么做
- 编写组件（就是上面的步骤）
- 在
src/api文件夹中对应的页面新建一个请求方法 - 在
src/api/XXXXX/types文件夹中定义请求和响应的类型 - 在
src/store/XXXXX文件中封装 api 文件夹中的请求 - 在页面中使用
src/store中的请求
后端我们使用了 MVC 的设计模式，以及类成员函数的主要编写方式，它具有极其良好的可扩展性
除了上面的两点，我们还做到了这些
- 统一的错误处理，错误处理全部在
src/error文件夹下 - 统一的路由管理，路由全部在
src/route文件夹下 - 统一的
Model定义，我们的 model 全部在src/model文件夹下
另外，我们将 MVC 的 Controller 拆分为了 controller 和 service 两个部分，我们在前面有提到过，对本系统后端来说这是极为良好的实践
举例，如果想要给后端新增加一个 API，可以这么做
- 在
src/route中新建这个 API 的请求路由 - 在
src/service文件夹中编写该 API 与数据库、缓存的交互 - 在
src/controller文件夹中编写该 API 与前端请求参数的交互，以及调用service
旧功能变更
和上面的步骤是一样的
系统迁移
我们目前正在用 Nuxt3 框架重构我们整体的项目，之后会有专门的文档