编程与软件工程mcfunley.com编辑精选
选择无聊的技术
Choose Boring Technology
2015 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
《Choose Boring Technology》是 Dan McKinley 的经典文章，提出“创新代币”概念：每个团队的创新预算有限，应把代币花在业务核心上，其余部分选用久经考验的“无聊”技术。文章在 2015 和 2020 年两度登上 Hacker News 首页，成为技术选型讨论中被反复引用的准则。
为什么经久不衰：它用简单的心智模型回答了每个团队都会遇到的技术选型难题，十年后依然适用于任何新项目启动时的决策。
HN 评论精选
区分“学习新技术”和“解决问题”两种动机，后者应只用一项新技术、其余全用熟悉的。
每次启动新项目，我都会诚实地问自己：我是把这个项目当作学习新技术的借口，还是在解决一个问题？如果是学习新技术，那很好，我只引入这一样新东西，其余都用熟悉的，出问题时容易排查。如果是解决问题，我就用已经掌握的技术——比如一个生成 HTML 的标准 Rails 应用。如果含糊地说“我要解决问题，但也许某个炫酷新技术是最好的方式”，那就是惨败的最短路径。我亲眼见过资金充足、人才济济的创业公司，因为工程师说服决策层采用满是流行词的架构，而没能按时交付。不了解你要用的工具，就谈不上知道什么是“正确”的方案，否则只是 cargo cult。
aaronbrethorst查看英文原文
Every time I spin up a new project, I try to answer the following question honestly: "Am I using this project as an excuse to learn some new technology, or am I trying to solve a problem?" Trying to learn some new technology? Awesome, I get to use one new thing. Since I already understand every other variable in my stack, I'll have a much easier time pinning down those 'unknown unknown' issues that invariably crop up over time. Trying to solve a problem? I'm going to use what I already know. For web stuff, this'll be a super-boring, totally standard Rails web app that generates HTML (ugh, right? How last century), or maybe a JSON API if I'm trying to consume its output in a native app. For mobile stuff, this'll be an Objective-C iOS app. Waffling about it and saying 'well, I am trying to solve a problem, and I think maybe a new whiz-bang technology is the best way to do it' is the simplest path to failing miserably. I've watched incredibly well-funded startups with smart people fail miserably at delivering a solution on-time because an engineer was able to convince the powers that be that a buzzword-laden architecture was the way to go. You don't know what the 'right' solution is unless you understand the tools and technology you'll use to deliver that solution. Anything else is just cargo-culting.
文章过于偏袒“无聊”技术；真正关键的是工程判断力，而非简单规则。
“创新代币”其实是良好工程判断力和在设计空间中迭代探索的替身。但“创新”和“无聊”都可能坑了你。文章只把“创新”当作风险，这很片面——这个行业不断把经验教训沉淀进共享的技术中。你回到 Rails 之前时代的代码库会不会尖叫？你去过一家从未吸收这些教训、用“无聊”技术重新造出旧日恐怖的“新”公司吗？（我两者都经历过。）陈词滥调式的规则不能替代持续在“理解问题—调研现状—用工程判断做选择”之间循环投入。
saidajigumi查看英文原文
The innovation tokens concept seems to be a stand-in for both good engineering judgement and iterative exploration of the design/implementation space before committing to a path. I've been in several (successful) startups that leveraged both of these principles to great effect. Both "innovative" and "boring" can shoot you in the foot. TFA focsues on "innovative" as a risk, but that's just daft. This industry is constantly rolling its lessons learned back into its shipped and shared technology. Ever gone back to a pre-Rails era web/backend codebase and screamed in horror? Ever gone to a "new" shop that never assimilated those lessons, used "boring" technology (thus dodging their shared/encapsulated forms), and recreated the old horror? (personally: check and check) Trite policies are not a replacement for spending dedicated up-front (and occasional ongoing) time cycling between 1) evaluating/understanding your problem, 2) researching the current state of the art {processes, technology, etc.} related to your problem, and 3) using good engineering judgement to choose the best path then-and-there.
从 noSQL 回归 SQL 的亲身经历印证：工具应该无聊，产品才应该精彩。
典型案例：我最近从 noSQL 回到了 SQL，因为我意识到很多 noSQL 只是在重新发明轮子。noSQL 可能有其适用场景，但大多数情况下 SQL 更好。前期稍多一点工作，换来的是数据组织良好、易于查询。SQL 是古老技术长青的典范，部分原因是它建立在数学和逻辑（集合论等）之上。你的工具不应该是令人兴奋的东西，你用工具构建的东西才应该是。
api查看英文原文
Case in point: I recently went back to SQL from noSQL after I realized that a lot of noSQL was just reinventing wheels. I realize there might be cases where noSQL databases shine, but in most use cases SQL is better. It's slightly more work up front (only slightly) but it pays off later in keeping your data organized and making it easy to query. It's a great example of a very old technology with excellent longevity. That's in part because it's built on math and logic (set theory, etc.). There are universal mathematical/logical truths encoded elegantly into the structure of the SQL language, and they describe things you are going to need. Your tools shouldn't be the exciting thing. The thing you are building with them should be the exciting thing.
“无聊”其实是“熟悉、长寿、好招人”的代名词，关键是避免未知的未知。
我仍然觉得“无聊”是个错误的词。应该选择：你了如指掌、能立即高效产出的技术；确定 5-7 年（最好 10-15 年）后依然存在的技术；你能舒服地招到接下来 15 名工程师的技术。这不意味着要选不舒适或古老的东西，核心是避免意外和未知的未知——创业时你没有时间从新手学起。很多极其成功的 MVP 恰恰是用作者非常熟悉的冷门技术实现的：ViaWeb 用 Lisp，YouTube 用 Python，最初的 Rust 编译器用 OCaml。
nine_k查看英文原文
I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choose exclusively among the top 5 most used in the field. The key thing here is to avoid surprises, unknown unknowns. You won't have the time to learn from a novice level while building a new company. A number of wildly successful MVPs were implemented with obscure (or then-obscure) technology which authors knew very well, and which boosted their productivity. ViaWeb was written in Lisp. YouTube was (and still largely is) written in Python, way before it was cool and well-known. The initial Rust compiler was written in OCaml.
现代技术栈的复杂度印证了文章观点：精简无聊的技术选型是优势。
如今即使中小型网站，技术栈也庞大得惊人：样式语言、前端框架、前端语言、后端框架、后端语言、消息总线，再加上基础设施即代码、至少两个 Web 服务器、两个 TLS 证书提供商……这正是文章的要点：选择一小套无聊的技术是优势，而不是什么可耻的事。
l0b0查看英文原文
As relevant as ever. It's fascinating how big web stacks are these days, even for small-to-medium sites: various combinations of at least one styling language (SASS/LESS/CSS), frontend framework (Angular/React), frontend language (JavaScript/TypeScript/Node.js), backend framework (Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java), and message bus (ZeroMQ/Redis/RabbitMQ). That's just the frontend and backend. Then there's infrastructure: pick at least three infrastructure as code components (Puppet/Chef/Ansible/k8s/Docker/Docker Compose/VirtualBox/WMWare/heaps of shell scripts), at least two web servers (Apache/nginx/traefik/your language's built-in server), and at least two TLS certificate providers because someone's nervous about moving everything to Let's Encrypt. I'm well aware that these don't have identical feature sets, but that's the point of the article: choosing a small and boring set of technologies is an advantage, not something to be ashamed of.
十年独立运营经验：SQL 约束、UNIX 脚本、少依赖、加硬件是长寿秘诀。
我靠一个 Web 应用自食其力超过十年，有些月份工作量不到一天。我把它归功于无聊的技术。最好的技术决策是：使用带大量约束、外键和索引的 SQL 数据库（相当于给数据加了类型）；依赖 shell 脚本和 UNIX 特性（十年后依然可用）；尽可能删除库和依赖（十年内 80% 会消失或大改）；用加硬件解决性能问题，而不是用花哨方案复杂化代码。
semicolonandson查看英文原文
I've boot-strapped and lived from a web-application for over ten years, some of which have involved less than one day per month's worth of work. I credit this to boring technologies. Looking back, the best technical decisions were: - using an SQL database with lots of constraints and foreign keys and indexes. It's like typing for data. - emphasis on shell scripts and leaning on UNIX features (since these continue working in ten years rather than being abandoned) - deleting as many libraries and dependencies as practical (over a ten-year time frame, 80% will disappear or change in ways that require huge mental RAM on your behalf) - a preference for paying for hardware to solve performance issues (vs. complicating the code with fancy solutions) For anyone interested, I go into more detail in this video https://www.youtube.com/watch?v=rQegYUsU7ec
历次讨论
同类还值得读
开源应用架构
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编辑精选