编程与软件工程danluu.com
为什么学校不教调试？
Why don't schools teach debugging? (2014)
2014 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dan Luu 在这篇经典文章中追问：为什么学校从不系统性地教授调试——这项工程实践中最核心的技能之一。他指出调试能力几乎全靠个人摸索获得，并分析了教育体系为何忽视它。文章多次登上 HN 首页，引发关于教育目标与实用技能脱节的长期讨论。
为什么经久不衰：调试是每个工程师每天都要面对却没人正式教过的技能，这篇文章把这一普遍痛点说透了，因此多年来反复被重新翻出。
HN 评论精选
调试是通用的排查思维，应在中学结合真实问题教授，而非在大学里脱离场景地讲理论
这种技能不该在大学学，而应该在中学学，而且它不只对 STEM 有用，对生活方方面面都有用。比如两个聪明人之间的分歧，往往可以通过'调试'各自的思路来化解；排查烤面包机为什么不工作、搞清楚妻子为什么离开你，也是同样的道理。它其实是两种能力：分析当前状态（看到了什么、预期是什么），以及回溯（从结果反推原因）。我们其实学过这些方法，但完全脱离实际场景——等真遇到问题、被复杂性压垮时，大脑根本不可能想起 20 年前学过的方法 A 能用在这里。教学不该是'理论→方法→应用→考试'，而应该是'理论→抛出问题→等提问→解释理论如何应用→复盘'。
erikb查看英文原文
It is a task that shouldn't be learned in university but in middle school. And it's not just useful to stem, it's useful to many things in life. E.g. a disagreement between two educated, smart people usually can be resolved by debugging how everybody got to their point of view and then flashing out the details. It's also how you figure out why the toaster isn't working any more, or why your wife left you. It's also actually two skills: Analysing a state. What do you see, what is there, or isn't. What was expected. Backtracing. Getting from point y to point x by figuring out how y happened. I'd say at least in my country we also actually learn these skills. But when we learn the methods its in a completely different context, totally unrelated to life. In real life, you hit a problem, you get overwhelmed by the complexity, and then your brain needs to start applying the method. In school you learn the method, no idea why. Then you apply it to totally theoretical problems, no idea why. Then you get tested on how well you execute the method, no idea why. Then nobody ever talks about it again. Now, how should your brain in moment of being overwhelmed remember that method A it learned 20 years ago may apply here? There's no way. Teaching shouldn't be: theory->method->application->test. It should be theory->enforce_problem->wait_for_questions->explain_how_theory_can_be_applied->review_of_application->goto:enforce_problem.
大学的目标是学术而非职业技能，教授们自己没靠调试成功，自然不认为它值得教
这恰恰暴露了 Dan Luu 的根本误解：他以为大学是教技能、为产业培养熟练工的地方。但大多数大学自视为为求知而求知的学术机构，只是碰巧培养出一些产业用得上的人。如果教授自己从不需要调试、用版本控制、写清晰的设计才能在学术界成功，他为什么会觉得这些值得教？这是学术界的幸存者偏差。人们把 STEM 培养体系想象成某个神明自上而下设计出来培养技术工人的机器，但体系中的不同参与者本来就有相互矛盾的动机。
solatic查看英文原文
> why schools don’t teach systematic debugging. It’s one of the most fundamental skills And herein lies Dan Luu's fundamental misconception: that universities see themselves as places where students come to learn skills, i.e. as places of certification producing skilled workers for industry. Most universities see themselves as academic places of learning for the pursuit of knowledge for knowledge's sake, which only incidentally graduates people whom industry happens to find their knowledge at least somewhat useful. If the university professor never needed to debug, use version control, or write clean designs in order to succeed in academia - why should he consider it worthy of being taught? If the university professor never benefitted from remedial review on his academic path towards becoming a professor, why should he consider it worth his time? Of course he's going to dismiss the notion to the tone of "some people just can't hack it in engineering." It's academic survival bias. People talk about the STEM pipeline like some kind of demigod figure designed it from on high specifically with the intent of producing skilled technical workers, albeit with various flaws related to sexism and skill relevance etc. Of course, this is a ridiculous way of looking at the STEM pipeline, so it shouldn't surprise anyone that different actors in the pipeline have contrary motivations.
先形成假设再用调试器验证，盲目单步调试只会造成隧道视野
费曼方法同样适用于调试。我教过书，见过太多初学者一遇到 bug 就打开调试器漫无目的地单步执行，完全不清楚代码本该做什么。等程序输出错误结果时，他们对错在哪毫无头绪——因为他们太专注于代码在做什么，而不是它应该做什么。我称之为'调试器诱导的隧道视野'。我的建议是：在用调试器之前，先想清楚并写下代码各关键点应有的条件和值，然后再用调试器验证这些假设。实践中，我带的学生往往在打开调试器之前就自己发现了 bug 的根源。
userbinator查看英文原文
I think the Feynman Method is equally applicable to debugging; I've also done some teaching before, and seen far too many beginners open the debugger at the first bug they find and start stepping aimlessly through the code, seemingly unaware of what their code should be doing. They eventually reach the point where the program outputs the wrong result, and have no better understanding of what they did wrong, because they were too focused on what the code is doing to think about what it should be doing. I call it "debugger-induced tunnel vision". My advice on this is to, before even thinking about using a debugger, think carefully about and write down if necessary the conditions and values expected at certain points in the code. Then, and only then, should you use the debugger to confirm or deny those hypotheses. In practice, with those I've taught, guiding them through this procedure, they often realise the source of the bug before using the debugger.
调试的本质是跨领域的通用诊断思维：列出可能原因、逐一排除，但学校从不教
更准确地说，学校不教的是通用的诊断能力——搞清楚东西为什么坏了。调试程序、诊断硬件故障、修汽车、修商用咖啡机，需要的技能几乎一模一样（这些我都大量做过）。修电脑时你脑子里有一张可能出问题的清单；修发动机时，你先确定症状（怠速不稳），列出可能原因（喷油嘴堵塞、真空泄漏、排气泄漏），再逐一排除。它们都遵循同样的模式：确定问题是什么、什么物理现象可能导致它、然后逐个排除。这不是我在学校学的，是我自己长大的过程中摸索出来的。
tsomctl查看英文原文
It's more like they don't teach general diagnosing/understanding why things don't work. I consider the skills needed to debug a computer program, to diagnose a hardware problem, to fix a car, and to fix commercial coffee brewers to be almost identical (and I have done all of these things, a lot). In fixing a computer, you have a mental checklist of all of the things that could contribute to it (failing hard drive, bad termination, failing memory, loose cable). In fixing an engine, you think of what the problem is (rough idle), what can cause it (plugged fuel injectors, vacuum leak, exhaust leak), and slowly determine which one is the culprit (probably not the fuel system, goes just fine 75 down the freeway. Oh, that vacuum line is disintegrating. Good job, Toyota). They all follow a similar pattern of identifying what the problem is, what physical manifestations can actually cause that problem, and then eliminating them one by one. This involves looking at the whole picture to narrow it down. This is not something I learned in school, I just figured it out growing up. I've found friends that don't necessarily know anything about computers, but are mechanically inclined, think similarly to how I do. I do have an innate desire to understand how everything works, and this definitely helps me understand what can physically cause the problem. That said, I did just take an Intro to Math Thought, for my math degree, and while it didn't really teach problem solving as I described above, it dramatically improved the way I thought about proving things rigorously.
历次讨论
同类还值得读
开源应用架构
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编辑精选