你有没有过这种时刻？拿到一个需求，脑子里第一个蹦出来的不是“怎么解决用户问题”，而是“哇，这个正好可以用我新学的XX技术栈/XX架构！”。然后兴奋地搞出一套无比精巧、自嗨十足的方案，最后要么难产，要么上线了也没人用。
说句大实话：程序员可以热爱技术，但千万别迷恋技术。迷恋技术的程序员，职业生涯天花板，会来得特别快。
一、醒醒！技术迷恋是一种‘病’，得治
危险一：你开始疯狂造轮子，而不是解决问题
有个经典案例：某大厂工程师迷恋“去中心化架构”，把一个简单的支付系统拆成了17个微服务。那个兄弟在评审会上讲得眉飞色舞，我们听得头皮发麻。
结果呢？一次简单的对账需求，要协调五个团队；一个小bug，排查了两天两夜。
迷恋技术的人总想用复杂方案解决简单问题，就像拿着手术刀切菜，还嫌弃菜刀不够精致。
危险二：你失去了商业判断力
在饿了么，我曾坚决反对过一个“技术驱动”的项目——用AI动态定价，算法复杂到需要博士才能看懂。我坚持用简单的规则引擎，原因很简单：出了问题，业务人员要能在一分钟内找到原因并调整。
后来竞争对手做了那个复杂的AI系统，一次故障直接导致当天订单量下跌30%，他们的CTO在会议室里问：“谁能告诉我，现在到底是怎么定价的？”
全场沉默。
危险三：你成了团队的‘毒瘤’
最怕遇到这样的技术leader：每个需求过来，他先考虑“技术挑战性”，而不是“业务价值性”。简单需求被复杂化，紧急需求被拖延，团队成员在“技术洁癖”中消耗激情。这种脱离业务价值的技术决策方式，最终会拖累整个团队的发展节奏。
二、看看那些混得好的：他们是怎么对待技术的？
在大厂待了多年，观察到一个现象：真正走到高位的，都不是技术最牛的，而是最懂“技术为业务服务”的。
我的前老板，前饿了么CTO，有句话我记到现在：“技术人员的价值，不是看你用了多牛的技术，而是看你帮公司赚了（或省了）多少钱。”
很俗，很真实。
迷恋技术的人容易陷入两个误区：
- 追求技术先进性，而不是适用性（你用了最前沿的框架，结果招不到人能维护）。
- 追求技术纯粹性，而不是实用性（你设计了完美的架构，结果需求一变全得重写）。
三、我是怎么戒掉“技术瘾”的？
2014 年以前，我也曾是个技术原教旨主义者。直到一次晋升答辩，评委问我：“你去年做的最有价值的事情是什么？”
我滔滔不绝讲了我的架构多么优雅，性能提升多少个百分点。
评委打断我：“说人话，这个架构帮业务增长了几个点？”
我答不上来。那一刻，我像被一道闪电劈中，从技术的云端直接跌回现实的地面。那一刻我明白了：在公司眼里，技术只是工具，商业结果才是目的。
从此我养成了三个习惯：
1、需求倒推法
接到需求先问：“如果不做这个，业务会损失什么？” 如果答案不明确，这个需求就不值得做。
2. 简单优先原则
能用一个if-else解决的，绝不用设计模式。代码的生命周期里，维护时间远大于开发时间。
3. 成本意识
每个技术决策都要算账：开发成本、运维成本、机会成本。用100万成本解决10万问题，那是败家。
四、给技术人的四个务实建议
1. 建立“业务-技术”翻译能力
你能用业务语言解释技术方案吗？试试把你正在做的项目，讲给你非技术的家人听，他们能听懂，你就算过关。
2. 追求“恰到好处”的技术
架构不是越复杂越好，而是能在当前资源下，最快速度支撑业务发展。饿了么早期用 PHP，Python，后来用 Java，还有部分场景用 Go，都是业务倒逼的。
3. 培养“交付思维”
你的价值不是写了多少行代码，而是交付了多少可用的、稳定的、有价值的系统。
4. 记住技术人的终极价值
用技术手段，以最低成本、最快速度、最小风险，实现业务目标。除此之外，都是自嗨。
写在最后
我说这些不是否定技术深度。技术深度很重要，它是我们的基本功。但技术深度要服务于业务理解的高度。
你看那些技术传奇人物：Linus写Linux是为了“好玩”，但让他封神的是Git——一个解决实际协作问题的工具；张一鸣学算法，最终做出了今日头条的推荐引擎。
他们的共同点：用技术解决真实世界的大问题。
所以，当你又忍不住想用最酷的技术时，先问问自己：这个选择，是让业务跑得更快，还是仅仅让我自己感觉更牛？
戒掉技术迷恋，不是放弃技术追求，而是把技术放在正确的位置。技术是桨，业务是船，用户要过河——别忘了我们要去哪里。
别用技术的勤奋，掩盖商业思维的懒惰。对于技术人如何平衡技术与业务，找到自己的成长路径，欢迎来云栈社区的开发者广场，与更多同行一起交流探讨。
发表于 昨天 16:12
|
查看: 6|
回复: 0
