🗒️是时候放弃全栈开发了

引用其他文章和评论

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

我放弃了成为一个全栈开发工程师的理想

https://www.infoq.cn/article/girkqeiw9yxat*k9ujfb

个人推荐

1. 前端还是要会一下简单的后端，比如node的一些web框架，在调试对接会更加丝滑，BFF可以完全上手

2. 后端也要懂一些前端，基本的to b管理端口页面可以写

推荐场景

1. 小公司、小团队、创业项目

2. BFF项目

3. 公司已经固定前后端全栈开发方式，提升效率

4. 招聘有经验多年的全栈开发，而不是找实习或者少量工作经验的全栈

不推荐原因

1. 在后端分布式、微服务、云原生、各种中间件时代，了解语言特性和中间件的基本原理和使用，保证业务高性能、高可用情况下，基本已经做到后端中高级工程师水平，做前端属于锦上添花，不会问题也不大; 目前正常体量公司做后端下面是一些最基本的技能点可以参考，如果不会去处理业务就会容易出现问题
1. 理解node或者java线程模型（主力编程语言肯定要了熟悉的）、redis、mysql 原子操作和分布式锁的含义
2. 线程池、连接池连接池复用（不要每次都去 new 一个，而不是复用）
3. web 服务的单例模式，AOP 和 IOC 依赖注入（一般方法都是单例，方法中的属性没有并发控制情况下一般读写都是有安全问题）
4. 丢数据的位置、原理
5. 合理的代码序列
6. 上下线造成的业务有损，异常重启停机导致数据的数据丢失
7. CPU高、内存泄露问题处理

2. 工作多年的一般都会专注一个领域，刚工作的专注一个领域会成长更快（刚入行的在业务熟悉之后，要深入了解基础技术为后续职业道路发展打下基础）

3. 没有严格的CR机制，处理一些问题就会前端一点后端一点，造成维护困难；（有些写出来的都是神奇的逻辑）

4. 这里我挺有赞 有赞霸王龙的故事。作为一个优秀的产品，把用户放在第一的企业文化，通过合理的组织架构和常规的实践方式保证系统的高可靠，我想为此多付出一些成本也是值得的。

5. 系统的不可靠、不稳定，会给公司所有人带来额外的压力，对客服售后团队造成巨大的工作量。

近期异常举例

1. 理解并发原子操作
1. 分布式下的原子操作要依赖分布式锁
2. node 单线程是针对一个同步方法而言

2. aba 分布式并发问题
1. 变量的 aba
2. 数据库的 aba(更新数据库状态的时候，加上状态条件；判断 effectRow 是否生效)
3. redis 的 aba 问题(redis 直接 increase 加减数据即可，取出再放入，原子是命令原子，取出计算中间过程就已经存在并发了)

3. 丢数据和状态更新异常
1. 参考 mq 丢数据（生产到 broker、broker 到 broker、broker 到 consumer）; 还涉及业务场景下对一致性的要求，分布式系统的ACK机制buffer到刷盘
2. 前端提交，少量数据保存，然后丢入队列，队列处理的时候再获取业务数据（中间链路越长出问题概率就也多；可能是代码问题、网络问题、异常重启、数据库闪断、并发问题）
3. 解决方法：对这些链路定时任务扫表重试，下游做好幂等处理、或者用户维度超时修正逻辑

4. 合理的代码序列
1. 包括一个数据库高可用HA切换闪断造成用户任务堵塞问题，代码序列先更新后续步骤数据状态，然后更新自身数据状态
   🗒️
   The MySQL server is running with the --read-only option so it cannot execute this statement

5. 动态队列限制（原本是静态限制）
1. 为了限制某个用户最大执行任务，增加最大限制，超出限制丢入队列重新跑
2. 在繁忙的时候问题不大，空闲的时候就会出现，100个并行处理，一个用户一次做多10个，超过设置延迟放入队列重跑
3. 只剩下一个用户的时候，就会出现队列不工作疑似卡死的问题，有更优雅的方式进行处理

6. 上下线有损
1. 任务批量提交，发布期间没有做优雅停机处理，导致丢数据
2. 不合理的代码编写，缓存泄露引起重启，导致丢数据