用户并不关心——但你应该关心

Lobsters Hottest 新闻

摘要

一篇博文论述:尽管用户不会直接关心代码内部结构,但良好的代码质量对于性能、修复漏洞和交付功能至关重要——这与“只有面向用户的结果才重要”这一常见套话相反。

<p><a href="https://lobste.rs/s/vufbvv/user_doesn_t_care_you_should">评论</a></p>
查看原文
查看缓存全文

缓存时间: 2026/06/08 03:15

# 用户不在乎——但你必须在乎 来源:https://lewiscampbell.tech/blog/260607.html 2026年6月7日 在我的职业生涯中,我一次又一次听到同样的陈词滥调。下面是一些实际例子: - "客户根本不在乎你的测试。他们在乎的是产品能用。" - "用户不在乎你的技术栈" - "首先你得接受:工程美感 ≠ 市场价值。" - "用户不在乎代码是AI写的还是手写的,也不在乎你用了什么框架。他们在乎的是产品能用。"¹ (https://lewiscampbell.tech/blog/260607.html#footnote-1) 这些话各有差异,但本质上是同一个主题的变体。老练的实用主义者正在告诉我们这个世界*真正*的运作方式。他向我们展示了一个冰冷而严酷的事实,而我们全都过于理想主义或目光短浅,看不到这个事实。"你折腾那个干什么?客户*不会在乎*的。" 关键问题在于,这全是扯淡。看看同样的陈词滥调套用到其他领域会怎样: - 道路使用者不在乎桥梁是否通过了最终检验。他们在乎的是桥梁能撑住他们的车。 - 乘客不在乎飞行员是否喝醉了。他们在乎的是飞机准时到达。 - 上班族不在乎摩天大楼的地基是否稳固。他们在乎的是赚钱。 表面上都没错。但都忽略了明显的下游影响。因为客户确实完全不在乎计算机代码的内在属性,这一点绝对正确。但下游影响是存在的: - 性能 - Bug 的存在 - 修复 Bug 需要多长时间 - 添加功能需要多长时间 你的代码越糟糕,解决这些问题就越困难、越慢。 当然,如果你是 Airbnb、OpenAI 或 Meta,你可以凭借惊人的市场占有率、庞大的风投资金和存疑的合法性,完全碾压这些顾虑。你*是*这样的公司,对吧? ## 民间智慧的持久性 认为只有一阶效应才重要,这种想法极其肤浅。然而这却是软件行业中一种极为流行的民间信仰。为什么? 很多人倾向于贬低或淡化自己不擅长的事情。如果一个人认识到自己写不出好代码,为什么不接受一种软件观——在这种观点里,写不好代码不仅无关紧要,反而那些**有能力**的人才是真正的问题?正是他们用客户甚至不在乎的东西拖我们后腿!快让我上线吧,兄弟。 所以我认为,这在一定程度上是一种自我防御机制。它让人可以回避自身的缺点,反而把问题外推到别人身上。你看那些书干嘛,书呆子? ## 我们生活在社会中 任何严肃的软件工程都是多种关切和多种视角的混合体。从技术销售到技术栈,从用户体验到唯一标识符。所有这些都促成了成功——或者失败。 1. Lobste.rs 版主:请不要给本帖打上"vibe coding"标签,因为这篇文章现在包含"AI"这个词↩ (https://lewiscampbell.tech/blog/260607.html#footnote-ref-1) --- 觉得我能帮到你的公司?联系我们 (https://lewiscampbell.tech/contact.html) 或访问我的咨询网站!(https://outdata.net/)

相似文章

为变更优化,而非应用性能

Hacker News Top

本文指出,软件团队常常过度优化微性能基准测试,却牺牲了开发者体验和工程吞吐量,而这两者才是长期交付速度与可维护性的真正瓶颈。

优秀的架构不需要胡萝卜,也不需要大棒

Lobsters Hottest

这篇博客文章主张,良好的软件架构应当是不言自明且毫无阻力的,倡导采用 Netflix/Spotify 式的“铺平道路”模式,而非依赖强制性的治理委员会或嵌入式架构师。

代码审查需要认真阅读代码

Lobsters Hottest

一篇开发者博客文章反对在不阅读 AI 生成代码的情况下直接将其部署到生产环境,强调代码审查具有至关重要的作用:分散责任、降低巴士因子风险,以及让团队成员保持对代码库的了解。

除了解决问题,什么办法都试过了

Hacker News Top

一篇博客文章,描述了行业资深人士发出的代码滥用警告如何导致关键工作流失败,但同事们没有修复滥用问题,而是提出了各种变通方案,比如添加更多输出处理器或抑制警告——这凸显了工程领域普遍回避解决根本问题的倾向。