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

前言

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

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

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

正文

一、问题

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

补充:

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

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

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

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

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

这个项目的github地址在这里

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

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

二、整改

1. 从MVP开始

先上线最小可用产品

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

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

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

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

技术是用来解决问题的

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

三、追问

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

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

显然不是的

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

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

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

最后

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

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

相关推荐
架构师沉默1 小时前
Java 状态机设计:替代 if-else 的优雅架构
java·程序员·架构
文心快码BaiduComate2 小时前
为什么编码智能体可以重塑开发范式?
程序员
AI大模型2 小时前
重磅!Ollama发布UI界面,告别命令窗口!
程序员·llm·ollama
AI大模型2 小时前
技术实践 | 几乎零代码!像搭乐高一样做AI应用,LazyLLM确实有点东西!
程序员·llm·agent
洛卡卡了4 小时前
人工顶不住,机审又烧钱,我只能硬着头皮上
后端·面试·架构
dylan55_you6 小时前
理解AI 智能体:多智能体架构
人工智能·ai·架构·agent·多agent
Liquad Li6 小时前
UML(统一建模语言)详解
架构·uml
风飘百里7 小时前
Go语言DDD架构的务实之路
后端·架构
猿java8 小时前
Feign如何实现负载均衡?它和Ribbon有什么关系?
面试·架构·负载均衡