编程与软件工程blog.kronis.dev
什么都别升级
Never update anything
2021 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章提出了一个反直觉的观点：不要更新任何东西。作者认为频繁升级依赖会消耗大量开发精力，主张保持稳定、只在必要时才动。评论区则普遍反驳这一立场，认为正确做法恰恰是经常小步升级，否则一旦遇到安全漏洞或被迫升级时会陷入地狱般的困境。
为什么经久不衰：它触及了软件维护中“稳定 vs 更新”的经典两难，隔了三年仍两度登上首页，说明这个争论至今没有标准答案，值得每个开发者思考自己的升级策略。
HN 评论精选
JS 生态的依赖维护成本远超其他技术栈，所谓“现代”反而拖累开发。
“当你的公司无法率先上市，因为大约 20% 的开发产能要花在跟上更新上”——在 JS 和 TypeScript 的世界里，这个比例更像 80%。我上一份工作中，那些 Node 新潮开发者五天里有四天都在和依赖、转译器、linter、打包器之类的东西搏斗，才能让程序跑起来。而那些搞 Java 服务的老兵却每个 sprint 都能稳定发布新版本，不需要什么英雄壮举。这些所谓“现代技术栈”到底怎么了，照顾它们竟要占掉开发者大部分时间？简直是噩梦。
abraxas查看英文原文
"When your company won't be the first to market, because about 20% of your total development capacity needs to spent on keeping up" In the world of JS and Typescript this ratio looks more like 80%. I swear that node hipsters at my last job spent four out of five of their working days wrangling with dependencies or their transpilers, linters, packagers, bundlers and whatever the hell else needs to happen to actually make a node program run. Meanwhile the geezers that worked on Java services reliably pushed new versions of their code sprint after sprint, no heroics, no drama required. What the fuck happened to those "modern stacks" that babysitting them takes the vast majority of developers time? It's a nightmare.
以真实教训反驳：不升级的代价更高，应该把升级常态化。
我欣赏这种反主流观点，但这听起来像缺乏实际经验的人说的话。我参与过一个从不升级的项目，后来 Spectre/Meltdown 爆发，我们被迫给所有系统打补丁，面对一堆过时依赖，花了几周才理清，简直是地狱。亚马逊一位首席工程师也说过，他们最大的错误之一就是升级不够频繁，导致每次升级都更痛苦。我们的做法是：用工具监控依赖过时和漏洞；把升级纳入日常开发流程；定期升级不活跃的包；大改动就建 ticket 当新功能处理。关键在于经常升级，这样就不会痛苦。
angarg12查看英文原文
I appreciate the contrarian point of view, and I don't want to pick on the author, but this sounds like words of wisdom from someone who doesn't have much real world experience. I worked in such a project who never upgraded once. And then Specter/Meltdown hit, and we had the mandate to patch all our systems (and the threat was very real). Welcome to a hellish mess of outdated deps that took weeks to sort out. But is not only me. I watched a talk from a Principal Engineer from Amazon builder tools, and one of their biggest mistakes was not to upgrade often enough, which made each upgrade more painful. So what do we do now working in multiple, large, multi-year projects? First, we set tools that tell us when deps are outdated, and alarm when vulnerabilities are found. Second, upgrading deps is part of the regular dev process. When you make a change, take the chance to upgrade the deps. Vulnerabilities are addressed proactively. The vast majority of times upgrades require no code changes. Third, we regularly upgrade deps of inactive packages. Lastly, if a dependency upgrade requires significant work, we create a ticket for it and address it as a new feature. In practice this happens very rarely, so it doesn't disrupt the development process much. As other's said, the key is to upgrade often, and then it wont be as painful.
高频小步升级让每次变更更小、更可控。
推论：更频繁地做难事，引用 Martin Fowler 的说法。随时升级一切，升级就永远不会难。你对破坏性变更有完整的上下文，而且从 A 到 B 的差异总是小于从 A 到 Q，也不太可能以奇怪而令人困惑的方式出问题。
web007查看英文原文
Corollary: Do hard things more often, per Martin Fowler - https://martinfowler.com/bliki/FrequencyReducesDifficulty.html Upgrade everything all the time and it will never be hard. You'll have full context for breaking changes, and the diff from A to B is always smaller than from A to Q, and less likely to break in strange and confusing ways.
建议用 LTS 版本加 Dependabot 自动化，避免被迫紧急升级的噩梦。
停留在仍接收补丁的最老小版本（通常是 LTS）是有道理的。可惜大多数开源库没有资源支持并行发布，所以要拿安全补丁就得跟上其他变更。最糟的处境是急着修一个 CVE，却先得把框架跨几个大版本升级并修复破坏性 API 变更。我宁愿每月交点小税，也不想冒那些通宵加班的风险。Dependabot 在这方面很好用，可以免费获取更新，或至少预览它们能否通过你的测试。
theptip查看英文原文
There’s something to be said for being on the oldest minor version that still receives patch releases (usually the LTS if there is such a thing). Unfortunately most FOSS libraries don’t have the luxury/resources to support parallel releases. So to get security fixes you need to keep somewhat up to date with other changes. The worst place to be is having to fix a CVE in a hurry, but first having to upgrade your framework a few major versions including fixing some breaking API changes. I’d rather pay a small tax every month than have to risk those late nights. Dependabot is great here, you can get updates for free, or at least preview if they are going to pass all your tests.
历次讨论
同类还值得读
开源应用架构
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编辑精选