❤️‍🔥对过度设计的反思

前言

在审视我目前做的项目的时候

发现了【过度设计】的问题

今天主要谈一下【过度设计

正文

一、问题

就拿我的个人网站来说,从最初的vue+springboot、到后面的vue+express、再引入微服务、再到后面的vue+nest+bff+微服务的混合架构

补充:

当然,这里面其实也包含了一些想用个人网站当技术演练场的想法。

所以我有了一个什么想法,想实践一些什么架构或技术,我就会优先拿个人网站项目开刀,这就导致我的个人网站的过度设计指数拉满了

⚠️这个其实有好处也有坏处,仁者见仁,后续不再叠甲。⚠️

只是我现在可能会偏务实一些,相比于一直堆架构/技术,现在可能会优先关注网站日活怎么样。

我印象很深刻的就是用过一个大佬写的websocket调试工具

这个项目的github地址在这里

没有什么花里胡哨地堆技术栈,一个朴实无华的html就写了大部分内容,并且这个工具还很好用。

我感觉不太对劲了,这不就是个简单的个人网站吗,似乎不用这么复杂才对啊。

二、整改

1. 从MVP开始

先上线最小可用产品

至于其他的功能,需要(或者预测即将需要)的时候再引入。

一个日活不到100的个人网站,其实单体架构就够用了,无需盲目堆砌架构或技术。

2. 引入技术前先考虑是否必要

要引入新技术前如果能说服自己引入这个技术的必要性,再引入

技术是用来解决问题的

不要为了堆技术/架构,反而带来了问题:如维护成本大大增加、大量占用服务器资源等等等等

三、追问

这样的话会有一个问题:这样一来,我猴年马月才能迭代到微服务啊?那我就一直不能接触他们?

这个问题其实很现实:如果没有足够的用户,那还接触不了微服务了?

显然不是的

回答:技术演练与生产环境应该分离

以我的个人经验来看,假如你想要【长期维护某一个项目并上线给别人访问、给别人提供某些服务】,那最好这个项目不要同时也是一个【技术试验场】。否则容易导致架构混乱、技术堆砌的情况。

比较推荐的方式是使用【Demo】的方式去进行相关技术、架构的练习,当生产环境中真的遇到了某些问题,再去【慎重、按需引入】。

最后

希望用户的【实际需求】成为技术选型的核心依据,

而非对新技术的盲目追逐。

相关推荐
字节逆旅4 小时前
从一次爬坑看前端的出路
前端·后端·程序员
AlbertZein4 小时前
HarmonyOS5 源码分析 —— ‘状态管理’如何管理的(1)?
架构·harmonyos
wenzhangli77 小时前
OneCode 3.0 前端架构全面研究
前端·架构
网络安全大学堂8 小时前
【网络安全入门基础教程】TCP/IP协议深入解析(非常详细)零基础入门到精通,收藏这一篇就够了
网络协议·tcp/ip·web安全·计算机·黑客·程序员·编程
拳打南山敬老院9 小时前
从零构建一个插件系统(六)低代码场景的插件构建思考
javascript·架构
ATM给我吐钱12 小时前
Trae,Trae,Trae,怎么还用上Trae Solo了?
程序员
用户479492835691512 小时前
同时用 VSCode 和 JetBrains 开发?这款插件让文件和光标 “无缝同步”
程序员
DemonAvenger13 小时前
Go语言实现高并发网络爬虫:技术实践与经验分享
网络协议·架构·go
老周聊大模型13 小时前
AI工程化必学:Spring AI与Redis的黄金组合实践
javascript·人工智能·程序员