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

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

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

https://www.zhihu.com/question/307749863

【回答1】

其实高并发对多数系统来说是个伪命题。

因为绝大多数公司的项目根本没有那么多用户，如果以为后端开发就一定意味着高并发就错了，实际上的用户也就几十、几百，却操着淘B、京D的心的人很多。

确定目标范围很重要，如果用户就那么少，就没必要过于操心高并发。

【回答2】

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

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

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

【回答3】

说实在的，你随便找个大公司的CTO去写增删改查真写不好。这种唯手熟尔的东西，人家根本没花时间在上面，写不好不是正常的吗？

你现在回去做高中数学题，你做的过高中生？怎么看待满嘴编码能力很强的人，数学能力还不如高中生？

上面这段话的含义我给你们抽象一下，该设计高并发架构的去设计高并发架构，并不需要写漂亮的CRUD。该写CRUD的去写CRUD，并不需要插足架构设计的问题。该写代码的去写代码，并不需要去做高中数学题。明白了吗？我没有任何一句话表示只需要高并发架构，不需要业务逻辑，也没有表示业务逻辑不重要。

我承认所有的架构都是为了支撑业务而存在的。但是你让一个架构师，去写业务代码？干嘛不直接找一个写业务代码的人来写业务代码？

【回答4】

工作年限不长，一线码农。简单谈谈看法和见解。入行之前觉得高并发性能问题是最高大上的。工作后才发现高并发性能问题其实更多的是通过物理增加机器、限流快速失败、服务降级来承载的。平时工作虽然没有接触到非常规的极致高并发，但是大促高峰期上万的qps还是很常见的。

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

其次重要的是软件工程的功底，很多人评价设计模式没用，但是如果没有对面向对象和设计模式有一定了解，连一些中间件的源码都啃不动。作为平台侧，最重要的就是如何承载多元多变的各种业务模式，以及如何让代码足够的灵活，足够方便扩展和维护。各种设计模式以及spi的应用是很多平台的核心。

【回答5】

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

高并发更招眼，更容易和面试官搭上话，很多面试官也就擅长这个，也更容易抬薪资。世面上的面试官很大概率是不太懂DB的，9成9的分不清全表扫和索引在哪种场景哪个效率高、基线分水岭在哪，1个查询的实现原理大概是什么、涉及几次IO ，几次随机寻址这类普遍重要又基础的问题。

这些问题经常贡献着业务各类性能问题90%的延时，但你看有几个SA关注，当然这种人统统写不出整体高效的业务系统。

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

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

以上。

==全文完==

欢迎大家交流！

做了一个“反焦虑”的职场发展的社群：

《40岁，创业2个月了，人生总得做点啥...》

一年至少50场活动，欢迎大家加入。

社群直播，每天30分钟，做啥副业最合适？欢迎参与。