是时候放弃全栈开发了

在你之后

于 2024-09-11 01:02:30 发布

阅读量433

点赞数 9

文章标签：全栈

本文链接：https://blog.csdn.net/qq_39517116/article/details/142112656

版权

引用其他文章和评论

我放弃了成为一个全栈开发工程师的理想_语言 & 开发_Artur Martsinkovskyi_InfoQ精选文章

全栈被小型企业所善待，被大型公司所摈弃。

至今还能听到有些前端或者后台的同学要走全栈（尤其是一些刚入门的同学），其实当深入到前端或者后台的技术之后，自然会打消这种想法，还有这种想法的同学，可能还不够专业，当然不能排除一些有精力饱满的人会深入前后端技术。

个人推荐

不推荐做不代表你可以不会、不学；只是现在上手成本现在已经略高了，专注一个领域达到这个程度都能拿到不错的薪资

更推荐刚入行的hxd，从容应对业务知识后，非头部企业或者业务复杂度特别高的行业，多学基础知识、底层原理，提高个人实力，拿一份体面的薪资

前端还是要会一下简单的后端，比如node的一些web框架，在调试对接会更加丝滑，BFF可以完全上手
后端也要懂一些前端，基本的to b管理端口页面可以写

专注一个了领域，另一个了解能用即可

不推荐原因

在后端分布式、微服务、云原生、各种中间件时代，了解语言特性和中间件的基本原理和使用，保证业务高性能、高可用情况下，基本已经做到后端中高级工程师水平，做前端属于锦上添花，不会问题也不大; 目前正常体量公司做后端下面是一些最基本的技能点可以参考，如果不会去处理业务就会容易出现问题
1. 理解node或者java线程模型（主力编程语言肯定要了熟悉的）、redis、mysql 原子操作和分布式锁的含义
2. 线程池、连接池连接池复用（不要每次都去 new 一个，而不是复用）
3. web 服务的单例模式，AOP 和 IOC 依赖注入（一般方法都是单例，方法中的属性没有并发控制情况下一般读写都是有安全问题）
4. 丢数据的位置、原理
5. 合理的代码序列
6. 上下线造成的业务有损，异常重启停机导致数据的数据丢失
7. CPU高、内存泄露问题处理
工作多年的一般都会专注一个领域，刚工作的专注一个领域会成长更快（刚入行的在业务熟悉之后，要深入了解基础技术为后续职业道路发展打下基础）
没有严格的CR机制，处理一些问题就会前端一点后端一点，造成维护困难；（有些写出来的都是神奇的逻辑）
这里我挺有赞有赞霸王龙的故事。作为一个优秀的产品，把用户放在第一的企业文化，通过合理的组织架构和常规的实践方式保证系统的高可靠，我想为此多付出一些成本也是值得的。
系统的不可靠、不稳定，会给公司所有人带来额外的压力，对客服售后团队造成巨大的工作量。

近期异常举例

最近接手一个全栈开发项目，项目属于多语言、分布式，维护过程中发现很多基础问题

理解并发原子操作
1. 分布式下的原子操作要依赖分布式锁
2. node 单线程是针对一个同步方法而言
aba 分布式并发问题
1. 变量的 aba
2. 数据库的 aba(更新数据库状态的时候，加上状态条件；判断 effectRow 是否生效)
3. redis 的 aba 问题(redis 直接 increase 加减数据即可，取出再放入，原子是命令原子，取出计算中间过程就已经存在并发了)
丢数据和状态更新异常
1. 参考 mq 丢数据（生产到 broker、broker 到 broker、broker 到 consumer）; 还涉及业务场景下对一致性的要求，分布式系统的ACK机制buffer到刷盘
2. 前端提交，少量数据保存，然后丢入队列，队列处理的时候再获取业务数据（中间链路越长出问题概率就也多；可能是代码问题、网络问题、异常重启、数据库闪断、并发问题）
3. 解决方法：对这些链路定时任务扫表重试，下游做好幂等处理、或者用户维度超时修正逻辑
合理的代码序列
1. 包括一个数据库高可用HA切换闪断造成用户任务堵塞问题，代码序列先更新后续步骤数据状态，然后更新自身数据状态 The MySQL server is running with the --read-only option so it cannot execute this statement
动态队列限制（原本是静态限制）
1. 为了限制某个用户最大执行任务，增加最大限制，超出限制丢入队列重新跑
2. 在繁忙的时候问题不大，空闲的时候就会出现，100个并行处理，一个用户一次做多10个，超过设置延迟放入队列重跑
3. 只剩下一个用户的时候，就会出现队列不工作疑似卡死的问题，有更优雅的方式进行处理
上下线有损
1. 任务批量提交，发布期间没有做优雅停机处理，导致丢数据
2. 不合理的代码编写，缓存泄露引起重启，导致丢数据