你怎么看待满嘴高并发，编码能力却稀松平常的程序员？

问题地址：https://www.zhihu.com/question/307749863

前情提要

遇到一些程序员，经常讨论和分享高并发架构的相关知识，神似大佬。但是写个SQL，用个MyBatis都费劲的人。不知道你们身边有没有类似的哥们。

补充描述一下编码能力稀松平常的体现：模块增删改查写起来费劲，需要技术上的指导，包含并不限于sql和Mybatis哦。

回答

整理了几个不错的回答，分享一下。

成隽的回答

写好 SQL 不容易，用透一个特定的 DB 就更难了，这个技能对企业其实很重要，但对个人来说这在目前国内是属于付出多回报低、性价比低的方向，DBA 和 DB skill 最值钱的年代过去快 10 年了。

高并发更招眼，更容易和面试官搭上话，很多面试官也就擅长这个，也更容易抬薪资。世面上的面试官很大概率是不太懂  DB 的，9成9的分不清全表扫和索引在哪种场景哪个效率高、基线分水岭在哪，1个查询的实现原理大概是什么、涉及几次 IO  几次随机寻址这类普遍重要又基础的问题。这些问题经常贡献着业务各类性能问题 90% 的延时，但你看有几个 SA  关注，当然这种人统统写不出整体高效的业务系统。

另个原因这些年在分布式缓存、nosql、sharding 方面的技术进步，通过分而治之、转嫁问题，很多设计很不合理的单机 IO 因为散到了多个 node  或磁盘上，似乎就没那么难看了，这种情况掩盖了很多问题，也提高了问题曝露的阈值和延时，使得那些原本的垃圾架构设计和烂架构师不太容易被识别出来，毕竟靠烧投资人的钱多堆点节点就满足了业务要求，看起来似乎也不那么烂了，即使其实离理论的单机极限差着十万八千里，也没人关心满足这类需求的min值其实在哪里。

毕竟现在国内上线速度、迭代速度、讲故事能力都比指望你个破程序员深入学 DB 榨取极限性能要重要多了。

举些例子：

1、见过一个强上 AKKA 替换 RPC 的 SA，鼓吹高并发，先进模型。用一堆判断 opcode 的 switch case 换掉了所有 RPC 调用做业务，导致各种混乱的回调依赖，编译期 bug 全整成了执行期 bug。然后项目死了，客户还不知道根本原因在哪，我方甩锅给业务复杂+开源弱鸡。这家伙还挂着高级 SA 混迹于多个项目。后来和 funding 过他项目的顾问聊，对方直接骂人了。

2、原东家有个海外 PM，中国人，给 AT&T 搞大数据业务分析系统，找人落地。部门经理安排我谈，10分钟谈崩了，傲的很，张口闭口你懂不懂大数据，懂不懂MR我毛了。我和经理说这家伙SX，瓢水还特牛逼，处不来。我带的几个下属后来进了这个项目。我离职时，我问他们这项目有没参考价值，给我截个 UI 看看，他们说瞎搞，老外也都不用了，一堆问题，搞构建的也闪人了，没人敢动构建，UI 服务器都启不了，现在大家就等着熬到项目结束，那家伙也早就靠这个项目回国跳阿里了，level 还很高。

SQL 写不利落正常，我写个 insert 现在都要找语法手册或抄下。

但如果给了你文档还不知道一眼扫哪段，遇到性能问题不说动手，连个诊断思路都没有，对你负责的业务访问 DB 的理论读写基线应该是多少都不知道，完全不知道怎么启监听，设cache，谈毛线架构高并发函数式，这说明你连独立部署在自己机器上玩下的能力和经验都没有。

这些人傻？别人营销头脑、政治手腕、心机棒着呢。

第一例子上 AKKA 的原因是这个人自己想上个 AKKA 项目以后好吹嘘，自己其实没用过。他私下对客户洗脑  AKKA 和 scala 多好多适合这个项目，背地对程序员这边鼓吹学值钱的新知识呀你才有价值呀才好跳槽呀，然后在没做原型、没评估数据的情况，某天开会突然向我和经理官宣“我们大伙研究过了都说好应该上”，经理一问，都说“嗯是的，上 akka 吧”，兵不血刃把架构换了，最后失败还拉着大家一起背锅，集体决策呀。

第二个例子更赞，东西做的稀烂，但他要求所有人必须认真写文档、用户手册和提交记录。别人告诉我，我还纳闷用户文档一般最后阶段补，能应付就应付，哪个项目会在过程中这么上心。然后给我看代码，就震惊了，我操客户项目直接开源了，他放着公司 github 企业账户不用，把项目挂自己的 github 私人账户的 public repo 上，要求所有人往他个人项目上提交。

这些人呢，祸害完项目，积累了足够多的能体现其牛逼的资本，就会去祸害下家公司，

厉害的是，除了少数懂技术的个人，他们还能看出，然大部分领导、客户不觉得他们烂，毕竟这么 nice、又能讲，还懂那么多词汇、业务、产品的人怎么可能烂呢，烂也是因为团队不给力、业务太复杂、技术上限就在那里呀。

上手写一个Recursive Descent Parser比浪费时间学怎么用gcc有用多了

有人怼我的，他觉得学 gdb gcc 工具链对新人没意义，说这是培训班路子，CS 科班谁信谁傻。

写 parser 愿意，觉得学下 gcc 用法都浪费时间的初学者。

嘴炮能人、PPT 架构师、投机者太多了，现在就这大环境。

中国从来不缺高瞻远瞩、高谈阔论的 CTO。

缺的是不那么操蛋、脚踏实地、实事求是、踩了无数项目坑、见识了无数不要脸，还愿意继续 coding 的大量资深码农。

匿名用户的回答

遇到同事，天天分享分布式锁/分布式事务/分布式系统/es。

但是看上去只是ppt很好看，但是没有什么内容，只是很模糊把一些东西弄到ppt上，看上去很强。

结果一个核心应用，自己写了内存泄漏。导致消息队列消费进程oom挂了。不会排查，一个线程每次读2k数据。gc没弄懂，硬是说什么6个消费者会把内存泄漏。刚上线半天，我发现监控消息队列堆积了，找他自己解决。结果弄了好久自己打的日志居然没找出报错日志。硬是要我一个没看过他代码的人根据经验瞎搜索错误一个个试关键词，最后找出报错日志是jvm+oom。然后他就开始瞎掰理由什么6个消费者瞬间消费导致内存超出限制。真气死一个线程读2k行，6个消费进程也就一万多行数据，能把你4g的的jvm堆用完?几百万的表都不一定有4g。自己不先复现就说是行太多就导致oom。

clickhouse+当MySQL表瞎join。clickhouse就是你们这样搞才天天不稳定。

拜托了，分布式事务不是调用一下seata api就是分布式事务啊。那样找一个会分布式事务的人不是很简单?连单机事务都没弄懂，弄几个官网的图照着念就会分布式事务。真的服了。你自己把偏序/全序弄懂了吗?

es真的连深分页都不知道怎么处理，就开始讲什么博客背过来的半对不对的倒排索引。但是你只会分享几个简单的es的crud。那种不是一天就能弄懂的吗?还需要你分享。

分布式系统，不是在yaml上面填上nacos地址就叫会微服务。你paxos总要弄懂吧?配置注入时机总要弄懂吧?

就离谱，没遇到事故的时候你说什么高大上的名词我都奉若神明。但是内存泄漏/不会排查问题/推卸责任/甩锅上下游。这就是你平时吹的分布式/高并发?

更新：重构完了前任留下的代码。把各种内存泄露/性能瓶颈都修了，现在运行平稳。

布朗尼的回答

但是有些人，确实是有些技术总监之类，如果不谈高并发就显不出自己高人一头，满嘴名词才彰显水平，也不能强求人家跟你谈的太LOW。

匿名用户的回答

我司有个同事也是，天天把高并发大数据挂在嘴上。代码写的稀烂，循环里打log，log还用中文。

在spring cloud gateway里用jdbc/redis template。我leetcode ac了1500+，和我说刷题没用，得有高并发海量数据的项目经验，我tm不知道啊…？那也得公司有啊。

年薪还是我的3倍，还真是让他踩到互联网红利了。

SeaSon的回答

背景：工作年限不长，一线码农。简单谈谈看法和见解。

入行之前觉得高并发性能问题是最高大上的。工作后才发现高并发性能问题其实更多的是通过物理增加机器、限流快速失败、服务降级来承载的。

平时工作虽然没有接触到非常规的极致高并发，但是大促高峰期上万的qps还是很常见的。

尤其站在平台侧，我是做电商交易和支付的，同时也负责一些基础中间件维护，我个人认为应对并发，最该考虑和关注的其实是分布式环境下最终一致性的问题。重复请求、消息重复消费、任务重复调度等问题，在高并发情况下分布式锁太重了，基本上单机层面通过数据库乐观锁控制，不同机器间靠幂等控制。

其次重要的是软件工程的功底，很多人评价设计模式没用，但是如果没有对面向对象和设计模式有一定了解，一些中间件的源码都啃不动。作为平台侧，最重要的就是如何承载多元多变的各种业务模式，以及如何让代码足够的灵活，足够方便扩展和维护。各种设计模式以及spi的应用是很多平台的核心。阿里中台这边收单、交易、逆向、营销、支付等域基本都已经集成在星环TMF下，所以中台这一套交易系统可以承载最普通的淘宝交易，也可以承载饿了么的外卖交易，也可以承载飞猪的机票火车票酒店门票的履约交易。这套交易系统提供上百个商业能力，支持各种业务去定制扩展点。这种架构能力是基于对软件工程的充分了解的，也是区分工程师能力的关键因素。