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