后端程序员最该掌握的技能，其实跟写代码无关
干这行十几年，我见过太多技术天才把项目带进沟里，也见过不少不太聪明的程序员把烂摊子收拾得漂漂亮亮。
一开始我以为是运气，后来发现不是。
差劲的程序员各有各的差劲，但牛逼的程序员都有一个共同点：他们知道怎么把技术问题翻译成人话。
技术最烂的，往往话也最烂
你有没有遇到过这种情况：
开会的时候，后端哥们balabala说了一大堆什么熔断降级、幂等性保证、消息队列最终一致性，产品同学听得脸都绿了，最后弱弱问一句：所以……这个功能周四能上线吗？
然后技术方案评审的时候，PPT画了几十张架构图，从微服务扯到云原生，结果测试同学问这个接口超时时间设多少，答曰：呃，应该问题不大吧。
这就是典型的技术语言和人类语言不通。
我管这叫程序员失语症——写代码的时候思路清晰，一让他解释技术决策，立刻变成一个复读机：因为这样更优雅、因为大厂都是这么干的、因为这个方案可扩展性更好。
你问他优雅在哪？呃……就是更优雅。
一个真实案例：一场本不该存在的撕逼
我带过一个项目，技术方案讨论的时候，后端和前端为分页接口该不该返回总数吵了整整两个小时。
后端说：查总数代价太大，数据库压力翻倍，不支持。
前端说：没有总数，前端分页组件没法用，必须支持。
两边各执一词，从技术吵到架构，从架构吵到KPI，最后老板出来拍板，各打五十大板，方案改成了第一页返回总数，后续不支持。
这是一个皆大欢喜的垃圾方案。
后来我介入复盘，问后端：你说查总数代价太大，到底有多大？
他支支吾吾：就是……很大……
我让他拿数据，他跑了一上午，给了我一个数字：查总数多消耗0.3毫秒。
0.3毫秒。
我问前端：你们真正需要总数干什么？
答曰：显示共XX条记录，让用户知道自己翻到哪了。
一个0.3毫秒的问题，加一个显示总数的产品需求，愣是被技术讨论成了哲学问题。
如果当时后端能说一句查总数多花0.3毫秒，但产品体验提升明显，值得，而不是这样不优雅，这场架根本吵不起来。
技术翻译能力的三层含义
我说的把技术问题翻译成人话，不是让你跟产品同学开会的时候少说术语。
这个能力其实分三层：
第一层：翻译给业务方
让非技术人员理解决策背后的为什么。
不是我们用了CQRS架构，而是这样做以后新增功能不需要改老代码，省时间。
不是需要做数据隔离，而是如果不做隔离，某用户可能会看到另一用户的订单信息，这是法律风险。
业务方听不懂的技术，都是废话。
第二层：翻译给协作方
让测试、产品、运营理解技术方案对他们的实际影响。
不是说接口做了缓存，而是说缓存命中率大概80%，部分请求会返回旧数据，如果发现数据不对，等5分钟再试。
不是说系统做了异步化，而是说用户点完下单会马上收到成功提示，但实际配网可能还要等2分钟，中间不要催用户。
协作方不需要懂技术，但他们需要知道技术在他们的工作里扮演什么角色。
第三层：翻译给自己
这一层最难，也是最重要的。
你有没有过这种感觉：设计方案评审的时候觉得自己想得特别清楚，文档写得特别完美，结果代码写了一半发现哪里不对劲，又说不上来哪不对？
这是因为你用技术语言思考，但代码要用实现语言落地。
翻译给自己的意思是：在动手写代码之前，尝试用非技术的日常语言描述你的实现方案。如果说不清楚，说明你自己也没想清楚。
我经常让团队里的人做这个练习：你怎么跟一个完全不懂代码的家人解释你今天写的这个功能？
能讲清楚的，代码基本不会差到哪里去。讲不清楚的，十有八九要返工。
为什么这技能比写代码本身还重要
有人会说：我技术牛逼就行了，沟通差点无所谓。
OK，那我给你讲讲现实：
第一，你的技术方案需要别人来执行。代码要测试、要前端接入、要运营配置。任何一个环节掉链子，你的优雅架构就是个屁。而让别人配合的前提是让别人理解。
第二，你的技术判断需要别人来背书。技术选型、技术方案评审，说到底是资源争夺。你要用别人听得懂的语言说清楚为什么值得投这么多资源，不然永远被业务方牵着鼻子走。
第三，你的职业发展需要这个能力。走到最后，技术专家要么走管理路线需要跟人打交道，要么走架构路线需要影响团队，这两个哪个离得开把话说清楚？
我见过太多技术天才，三十五岁以后开始焦虑天花板。问他们焦虑什么，答曰：感觉技术这条路走不通了。
其实不是走不通，是走到一半发现自己只会跟机器说话，不会跟人说话。
怎么练这个技能
四个字：强制输出。
不是什么多练习沟通这种废话，是有具体操作方法的。
方法一：每次技术方案，写一份外婆版
写完技术文档之后，再写一份给外婆看的版本。如果外婆看不懂你的技术文档，你的技术文档就是不合格的。
这不是让你写得幼稚，而是让你提炼出真正核心的东西。
方法二：每次别人问你技术问题，别直接回答
先问一句：你问这个问题是为了解决什么？
然后根据他的回答，用他的语言来解释你的技术。
举个例子：
对方问：这个接口的QPS能抗多少？
你问：你是想评估要不要加缓存？还是想确认高峰期的稳定性？
对方说：我想确认高峰期会不会挂。
你答：高峰期我们机器能扛住的量是平时三倍，而历史峰值是平时的1.5倍，留了安全余量，不会挂。而不是：
QPS大概5000，单机扛1000，5台机器，加上有缓存，实际能到8000左右……同样的信息，不同的翻译方式，信任度完全不一样。
方法三：每季度做一次最烂翻译复盘
回顾这季度你参与的所有技术沟通，把那些说了半天对方还是一脸懵逼的场景记下来。
然后问自己：如果让我重新说一遍，我会怎么说？
时间长了，你会发现自己踩的坑越来越少。
说到底，编程也是一种翻译
其实你仔细想想，编程这件事本质上就是在做翻译——把业务需求翻译成机器能执行的代码。
一个需求转代码都转不好的人，你能指望他跟产品沟通的时候翻译得多清楚？
反过来说，一个能把技术问题翻来覆去用不同方式讲清楚的人，写出来的代码通常也不会差——因为他在写代码之前就已经在脑子里把业务语言和技术语言对照清楚了。
所以别再觉得沟通是软技能不重要。
能把话说清楚的人，写代码也不会太烂。这是我十几年观察下来最灵的规律之一。
当然，如果你看完这篇文章还是觉得我技术牛逼就行，那我只能祝你好运。
毕竟，牛逼的技术方案，配上一份谁也看不懂的文档，在职场里的实际价值约等于零。
你自己掂量吧。
