编程与软件工程saagarjha.com
我们 $知名公司 换用了 $热门技术
We at $Famous_company switched to $Hyped_technology
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是一篇讽刺文章，作者以模板化的占位符（$Famous_company、$Hyped_technology）戏仿了科技公司博客上常见的“我们迁移到某热门技术”的套路文章：夸大旧技术的问题、用模糊指标宣称重写大获成功、结尾附上没用的开源代码和招聘链接。作者自述写作时开着多篇此类真实博文作参照，纯属调侃。
为什么经久不衰：它精准戳穿了技术选型博文的宣传套路，提醒读者别盲目照搬大公司的决策——这类迁移故事年年出现，这篇戏仿因此多年不过时。
HN 评论精选
引用文中两段最辛辣的讽刺，点出对 GC 参数瞎调、开源作秀的嘲弄。
太好了，读到这两段我笑出了声：'起初我们试着调了一些自己并不理解的垃圾回收参数，但出乎意料的是这并没有神奇地解决问题，于是我们干脆把 GC 整个关掉了。这增加了内存占用，不过我们的按需自动扩容器帮我们搞定了，如下图所示'；'今天我们把那些开源得起、也不怕开源的代码放到了 GitHub 上。它本身没什么用，而且和我们的基础设施深度耦合，但你可以给它点个 star，让我们显得更有影响力。'
est31查看英文原文
Nice, I laughed out loud when I read these two paragraphs: > Initially, we tried messing with some garbage collector parameters we didn’t really understand, but to our surprise that didn’t magically solve our problems so instead we disabled garbage collection altogether. This increased our memory usage, but our automatic on-demand scaler handled this for us, as the graph below shows > Today we are making some of the code that we can afford to open source available on our GitHub page. It is useless by itself and is heavily tied to our infrastructure, but you can star it to make us seem more relevant.
作者现身说法：文章是戏仿多篇真实博文写成，意在提醒读者别盲从大公司的技术决策。
唉，标题好像被弄乱了……算了。正如大多数评论者看出来的，这基本是半开玩笑写的；我写作时开着好几个这类博文的窗口作参照，所以你也许能从中认出一些熟悉的公司和技术。不过我很乐意听你们讲雇主的技术决策过程，所以不想劝阻任何人写这类博文。只是请记住，你们的决策未必适合别人。反过来说，如果你自己在做技术决策，$FAMOUS_COMPANY 的做法有时也未必是你的正确选择 :)
saagarjha查看英文原文
Sigh, it looks like the title got a bit mangled…oh well. As most of the commenters have gathered, this was mostly tongue-in-cheek; I kept a window with a few of these kinds of posts open as I wrote so I could refer back to them so if you might be able to make out some familiar companies or technologies in there. That being said, I love hearing about your employer's technical decision making process, so I don't want to discourage anyone from writing blog posts like these. Just try to keep in mind that your decisions not be the right ones for everyone else. On the flip side, if you're looking to make technical decisions yourself, sometimes what $FAMOUS_COMPANY did is not the right choice for you :)
指出真实世界中团队为证明重写 ROI 而粉饰指标的普遍现象。
'重写之后，所有对我们重要的指标都大幅提升，我们甚至发现有些指标已经不再相关，比如 bug 数量、用户挫败感和维护成本。'这种事发生得比我想承认的还多：大规模翻新，$new_thing 在很多方面确实有改进，但带着一个没经过多年打磨的新系统所有的可靠性和成熟度问题。可团队觉得必须证明重造轮子的投资回报，于是把指标修饰成毫无疑义的成功，而一线的每个人都心知肚明并非如此。
munchbunny查看英文原文
> Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost. That has happened more than I'd like to admit: massive overhaul effort, $new_thing is an improvement in many ways but has all of the reliability and maturity problems of a new system that hasn't gotten years of patches. But the team feels like they have to show ROI on reinventing the wheel, so they massage the metrics to look like an unambiguous success, when everyone involved at the ground level knows it wasn't.
失败的重写往往无人复盘，其宣传文档却持续误导后来的小公司。
这篇文章很好，但要记住它只是 $Famous_company 故事的第一步。有些重写是简历包装和无害的公关；有些确实成功了；但还有些时候，结果是彻底失败。最令人难过的情况是：$Hyped_technology 失败了，但 $Famous_company 投入太多、技术负责人押上了太多声誉，不愿公开谈论。于是听过演讲、读过博文的小创业公司们心想：大公司都用它，肯定够我们用！……结果并不够，大量昂贵的工程师花了很多时间收拾残局、彻底弃用 $Hyped_technology。而当初宣传这一决策的'地雷文档'依然到处流传，甚至被 $Hyped_technology 的销售工程师引用。
hibikir查看英文原文
The post is great, but it's important to remember it's only a first step in $Famous_company's story. Some rewrites are resume padding and PR to get more hires, and a talk a big conference, but are rather harmless. Others succeed, and were good ideas. But other times, the result is a big failure. One of my personal favorites involves a $Hyped_technology having a well defined trap that then leads us to another article, 1 to 2 years later, explaining how they migrated away from $Hyped_technology, often to something boring. But the really sad outcome is that $Hyped_technology is a big failure, but $Famous_company spent too much effort, and $Famous__technical_person too much of their social capital, to want to talk about it. Then all kinds of little startups that have heard the talks, read the blog posts, and then decide that if the solution was good enough for $Famous_company, it must be good enough for them!... except that it wasn't, and a lot of expensive engineers spent a whole lot of time making things work again, abandoning $Hyped_technology altogether. Unfortunately, the landmine documentation advertising the decision is still everywhere, including getting referred to by sales engineers of $Hyped_technology.
用亲身经历印证文中'招不到人'这类换栈理由背后常是降低人力成本的算计。
'但最终，促使我们切换的其实是难以给 $UNREMARKABLE_LANGUAGE 招到新人才，尽管它在几十所大学都有开设。'这在之前的公司是真实的换语言换技术栈的说辞。某天 CTO 和 HR 算了一笔账：长期来看，用新语言重写服务、招便宜而充足的开发者，比招更多熟悉现有技术栈的人并继续扩展更划算，因为后者的市场平均薪资更高。
awb查看英文原文
This is akin to my pet peeve dev team blog post: We had to scale our $STANDARD_LANG application. Turns out it wasn’t fun. But you know what is fun? Writing tiny, non-essential MVPs in $SHINY_LANG. We haven’t tried scaling our $SHINY_LANG apps yet or deploying to production, but we’re excited about the future and we’re enjoying coding again!
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选