编程与软件工程nathanmarz.com
以痛苦为导向的编程
Suffering-oriented programming
2012 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Nathan Marz（Storm 的作者）关于“suffering-oriented programming（以受苦为导向的编程）”的博客文章。核心主张是：先直接用最笨、最直接的方式解决自己真正遇到的问题，亲身体会其中的痛苦，再据此重构出最小、最合适的抽象；不要预先设想自己其实没有的使用场景，否则容易过度设计。文中以 Storm 为例，说明如何把实时计算领域提炼成 streams、spouts、bolts、topologies 等少量抽象。
为什么经久不衰：它点中了软件开发中“过度设计 vs. 务实解决”的长期张力，并把重构视为对抗意外复杂度的关键，因此十几年后仍值得读。
HN 评论精选
补充了 Storm 用异或计数判断所有 tuple 处理完成的实现细节。
“用 Storm 时，我把实时计算的问题域提炼成一小套抽象：streams、spouts、bolts 和 topologies。我还设计了一个保证数据处理的算法，去掉了中间消息代理——那正是我们系统里复杂度和痛苦的最大来源。”作为细读过 Storm 源码的人，我来说说他是怎么做到的：他把每个待处理的 tuple 做哈希，然后异或进一个初值为 0 的变量；处理完成后，再把它异或回去；当这个变量回到 0 时，他就知道全部完成了。我觉得挺巧妙的。
3pt14159查看英文原文
"With Storm, I distilled the realtime computation problem domain into a small set of abstractions: streams, spouts, bolts, and topologies. I devised a new algorithm for guaranteeing data processing that eliminated the need for intermediate message brokers, the part of our system that caused the most complexity and suffering." As someone who has gone through the storm source in very fine detail, let me tell you how he did this. He hashed each tuple that needed to be processed then XOR'd it into a variable that started at a value of zero. When the piece that needed to be processed was complete it would get XOR'd back into the variable. Once the variable hit 0 he knew everything was done! Pretty neat if you ask me.
指出这种思路的副作用：自己的痛点一解决，项目就失去继续完善动力。
这种方法（我很喜欢它）最大的问题是：它让人很难“做完”。比如圣诞节期间，我花大约四小时写了一个能用的、伪自然语言的 iTunes 命令行控制器，然后花几天加语音识别、Web 界面这些半成品的疯狂功能，接着就基本停止开发了。不是因为它变无聊了，而是因为我自己的问题已经解决了——不优雅、不高效，但问题没了。问题在于：一旦“痛苦”消失或足够减轻，就没有真正理由继续构建了。
csl_查看英文原文
The biggest problem I have with this approach (and believe me, I love this approach), is that it makes it hard to finish things. For example, over Christmas, I built a small pretend-natural-language CLI controller for iTunes. I made a working version in something like four hours, spent a few days adding in crazy half-thought-out features like speech recognition and a web interface - and then I basically stopped development. I didn't stop development because it got boring - I stopped development because I'd solved my own problem. Not beautifully (certainly not from a coding perspective), not efficiently, but the problem I had was solved. The problem, then, is that once the "suffering" is gone, or sufficiently lessened, there is no real reason to keep building. (oddly, my password for my old account no longer seems to work. I was hebejebelus)
支持只暴露核心 20% 的接口，反对为臆想需求堆砌 API。
试图预判你实际并不存在的使用场景是个错误，否则你最终会把方案过度工程化。我希望更多人在用噪声破坏自己本来好好的 API 之前能这样想。这方面我很推崇帕累托原则：首先暴露那 20% 能让我达到 80% 效果的部分，其余可以边做边想；至少今天你教我的东西，我能学得快、记得牢。
mekoka查看英文原文
It's a mistake to try to anticipate use cases you don't actually have or else you'll end up overengineering your solution. I wish more people would think like this before sabotaging their perfectly good APIs with noise. I'm a huge fan of the Pareto principle in that regard. First and foremost, expose the 20% that allows me to be 80% effective. The rest can be figured out as we go, but at least, what you'll teach me today, I'll learn fast and will know well.
认同持续重构，但指出它依赖个人对代码的深度熟悉，大团队中会成为瓶颈。
这段话很有共鸣：“以受苦为导向的编程者最重要的特质是坚持不懈地重构。这对防止意外复杂度破坏代码库至关重要。”我见过太多次：有人加新功能却不花时间重构成最简单的一套抽象，于是意外复杂度悄悄渗入。但这也正是该方法的缺陷——你必须成为代码专家才能提炼出这样的抽象，而当代码库大到需要多个开发者时，这就成了瓶颈，不是每个人都有时间或能力成为专家。
tim_h查看英文原文
This resonates: > The most important characteristic of a suffering-oriented programmer is a relentless focus on refactoring. This is critical to prevent accidental complexity from sabotaging the codebase. I can't tell you how many times I've seen accidental complexity creep in because someone adds a new feature without taking the time to refactor to the simplest set of abstractions. But - and here's the flaw in the approach - you have to be an expert in the code to produce such a set of abstractions, which is a potential bottleneck when your codebase is big enough to require multiple developers. Not everyone has the time/capability to be an expert.
历次讨论
同类还值得读
开源应用架构
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编辑精选