前言
在审视我目前做的项目的时候
发现了【过度设计】的问题
今天主要谈一下【过度设计】
正文
一、问题
就拿我的个人网站来说，从最初的vue+springboot、到后面的vue+express、再引入微服务、再到后面的vue+nest+bff+微服务的混合架构。
补充：
当然，这里面其实也包含了一些想用个人网站当技术演练场的想法。
所以我有了一个什么想法，想实践一些什么架构或技术，我就会优先拿个人网站项目开刀，这就导致我的个人网站的过度设计指数拉满了
⚠️这个其实有好处也有坏处，仁者见仁，后续不再叠甲。⚠️
只是我现在可能会偏务实一些，相比于一直堆架构/技术，现在可能会优先关注网站日活怎么样。
我印象很深刻的就是用过一个大佬写的websocket调试工具
这个项目的github地址在这里
没有什么花里胡哨地堆技术栈，一个朴实无华的html就写了大部分内容，并且这个工具还很好用。
我感觉不太对劲了，这不就是个简单的个人网站吗，似乎不用这么复杂才对啊。
二、整改
1. 从MVP开始
先上线最小可用产品
至于其他的功能，需要（或者预测即将需要）的时候再引入。
一个日活不到100的个人网站，其实单体架构就够用了，无需盲目堆砌架构或技术。
2. 引入技术前先考虑是否必要
要引入新技术前如果能说服自己引入这个技术的必要性，再引入
技术是用来解决问题的
不要为了堆技术/架构，反而带来了问题：如维护成本大大增加、大量占用服务器资源等等等等
三、追问
这样的话会有一个问题：这样一来，我猴年马月才能迭代到微服务啊？那我就一直不能接触他们？
这个问题其实很现实：如果没有足够的用户，那还接触不了微服务了？
显然不是的
回答：技术演练与生产环境应该分离
以我的个人经验来看，假如你想要【长期维护某一个项目并上线给别人访问、给别人提供某些服务】，那最好这个项目不要同时也是一个【技术试验场】。否则容易导致架构混乱、技术堆砌的情况。
比较推荐的方式是使用【Demo】的方式去进行相关技术、架构的练习，当生产环境中真的遇到了某些问题，再去【慎重、按需引入】。
最后
希望用户的【实际需求】成为技术选型的核心依据，
而非对新技术的盲目追逐。