“手雷的人”第一眼看到这四个字大多数人会以为是在聊军事装备。如果放到程序员语境里就容易理解了大概率是输入法把“手撸代码的人”打成了“手雷的人”。所谓“手撸”就是亲自动手写代码也泛指活跃在一线的开发者。这句话的真实意思是有些人觉得搞技术的人脑子里装的全是二极管——判断任何问题都只有两个方向要么全对要么全错中间状态不存在。这个吐槽确实有点极端但它值得技术人认真想一想为什么技术圈里那么多争论都没有结果编程语言之争、前端框架之争、数据库之战、微服务和单体之争吵了几轮下来双方引用的数据都没错结论却完全相反。问题往往不在技术本身而在认知方式。当一个人习惯用“二极管理论”去参与技术讨论他很容易把“适合某一个业务场景的方案”误解为“唯一正确的方案”然后把自己推进无休止的争吵里。这篇文章要讨论的就是这种非黑即白的思维模式在技术工作中的具体表现以及如何避免它。我会从原理讲起再落到技术选型、代码评审、架构决策的实际场景最后给出一套可以直接复制使用的评估脚本、ADR模板和评审清单。读完以后你至少能获得三个有长期价值的能力能识别自己或团队是否陷入了二极管思维能把一个充满情绪的技术争论转化为可量化、可评估的技术问题能在关键决策时留下书面依据而不是靠嗓门和资历做判断。1. 这篇文章真正要解决的问题先明确一下这篇文章不是批判某个群体也不是教人“做人要圆滑”。工程判断上的灰度不等于和稀泥。灰度是承认约束条件承认成本承认不确定性然后基于证据和业务目标做选择和稀泥是没有标准没有结论谁都不敢得罪。两者看起来都“不极端”但在工程实践里是完全相反的行为。当下开发者面对的真实困境是信息严重过剩观点严重过剩但能用的决策框架很少。你在搜索引擎里输入任何一个主流技术关键词都能看到大量“XX已死”“XX是垃圾”“有XX就不需要YY”的标题。这些内容之所以存在是因为极端观点更容易获得点击点击量又反过来刺激更多极端内容生产。于是一个本来应该靠数据、场景、成本综合判断的技术问题被简化成了站队问题。这就是本文要解决的核心问题帮你建立一套“上下文优先”的技术决策习惯把“XX好不好”改成“在什么条件下XX更合适”。如果你是技术负责人或者架构师你还需要学会把这种习惯变成团队的流程避免每次技术选型都变成一场消耗团队精力的辩论赛。最适合读这篇文章的人包括正在做技术选型、但又怕被网上极端观点带偏的开发者在代码评审中经常因为风格或方案问题跟同事争论的技术人经常参与架构设计、需要为团队决策负责的技术Leader以及所有想减少无效争论、提高工程协作效率的人。2. 什么是“二极管思维”从电子元件到开发者的认知误区2.1 二极管的物理特性与网络流行义二极管是一种基础电子元件最核心的特性是单向导电性外加正向电压时导通外加反向电压时截止。它强调的是状态明确、行为可预期这正是电子电路里非常宝贵的特性。借用到人的思维方式上“二极管”就变成了一种生动但略带贬义的比喻说话做事只有两个极端状态没有中间量。这个比喻在程序员圈子里流传很广不只是因为它形象地对应了电子元件还因为它精准地描述了很多人观察到的现象——技术讨论中经常有参与者把复杂问题折叠成两个对立的标签“好”与“坏”“正确”与“错误”“值得学”与“没必要学”。你很难让他们承认世界上的技术方案绝大多数是“在特定条件下某一方更合适”。2.2 二极管思维的三层结构为了避免把“二极管思维”当做一个空洞的帽子我把它的典型表现拆成三层方便对照自我检查有倾向性。这是最外层也最正常。任何一个有经验的工程师都会对某类技术更熟悉、更偏好。倾向性本身不是问题。过度简化。中间层是问题开始出现的信号。典型表现是把多维度的问题压缩成一个维度。比如说“这个框架性能比那个好所以它一定更优”忽略生态、团队、运维成本、迁移难度。立场化。最内层也是危害最大的地方。当一个人把技术偏好和身份认同绑定“选A还是选B”就变成了“我和你是不是一路人”。一旦到了这个阶段反对一个技术方案就会被当事人解读为否定他的专业能力讨论就会失效。你可以用这个三层结构检查自己遇到一个技术争论先问自己我是在表达经验还是在简化问题还是在维护自己的立场如果已经在第三层最理性的做法是暂停争论回到数据和场景。2.3 二极管思维和工程思维的本质区别工程思维默认每一件事都是设计出来的设计必然有约束约束必然带来取舍。而晶体管只有两种状态是因为它不需要处理多种情况软件系统面对的约束条件极多用户规模、团队能力、部署环境、成本预算都不同。因此工程世界里常见的正确答案往往是多目标优化后的次优解而不是某个维度上的最优解。举个最简单的例子在面试时面试官问你“单体和微服务怎么选”如果回答“微服务是趋势必须用”大概率不会拿高分如果回答“要看团队规模、业务复杂度、部署能力小团队单体更经济团队规模和业务复杂度上来以后再拆”这才是工程思维。技术社区遍地都是前一种回答但真实项目需要的是后一种。3. 为什么程序员最容易陷入二极管思维上一章讲了什么是二极管思维这一章要往前追一步为什么搞技术的群体尤其容易掉进这个坑3.1 编程世界的确定性环境编程语言执行代码要么通过要么报错测试用例要么通过要么失败线上服务要么正常要么宕机。程序员长期生活在大量确定性分界的环境中会慢慢形成一种思维惯性二元判断是高效且可靠的。这种惯性延伸到工程决策、团队协作中就会变成对“唯一正确解”的过度追求。事实上代码编译和工程决策是两种性质完全不同的问题前者有明确标准后者没有。3.2 应试与面试训练出来的“标准答案”习惯从学习编程到参加面试我们大量时间是在寻找标准答案算法题有最优解框架API有推荐用法性能调优有固定的招式。这种训练对打基础很重要但它会带来一个副作用——遇到开放性问题时会下意识地找“那个正确答案”甚至认为找不到正确答案就是讨论者不专业。3.3 沉没成本与身份绑定一个老程序员写了很多年Java让他承认在某个特定场景下Go更合适会感觉像在否定他过去十几年的投入。这是沉没成本效应在起作用。更复杂的是技术栈在职业生涯中会变成身份标签“我是搞Java的”“我是搞前端的”。当技术选型遭遇质疑当事人感受到的不仅是方案被否还有身份被挑战。这时讨论自然就从技术层面滑向情绪层面。3.4 社区反馈机制的激励技术社区的内容生产机制天然倾向于奖励极端观点。标题越有冲突感完读率越高观点越鲜明评论区越热闹。在流量逻辑下“XX已死”“远离XX”这类内容源源不断地被生产出来而理性分析因为没有劲爆观点很难传播。长期泡在这些信息里人会越来越倾向于用极端方式表达自己。3.5 团队缺少决策过程显性化机制最后也要承认一个现实很多团队在做技术决策时没有显性的流程。不开会直接拍板的有开会吵一架后由最资深的人拍板的有查一场网络资料然后投票的也有。这些方式都没有把“决策依据”记录下来导致下一次遇到类似问题又要重新吵一遍。过程不透明、标准不统一大家当然只能用立场对抗立场。4. 二极管思维在技术选型与代码评审中的表现4.1 技术选型从“
