网页 综合 更新时间 2026-10-14 15:00:00

Debug by Stepping, Not by Printing - Vets Who Code

自动蜘蛛 vetswhocode.io 正文约 4176 字
Debug by Stepping, Not by Printing - Vets Who Code
New Cohort Starts: Apr 05, 2027
Every engineer has debugged with console.log. It's fast, it works everywhere and it's often enough. The trouble is that a print statement can only answer a question you already knew to ask. When the bug lives somewhere you didn't expect, you add a print, rerun, add another, rerun again, and slowly surround the problem. A debugger lets you stop the program at the moment things go wrong and look at everything.
This is the third post in our series on how Vets Who Code teaches code review, debugging and testing, written for the engineers who'll work alongside our troops.
The editor domain page lists Debug with breakpoints: "sets breakpoints, inspects state and walks the call stack." Its evidence criterion:
Finds a bug by stepping rather than by print
The exit depth is unassisted. The neighboring topic, Configure a debug launcher, goes one step further, and its criterion is that the troop "attaches a debugger to a running server."
We don't ban print debugging. We require that a troop can do the other thing, so they can choose.
The weekly calendar shows every event on every day.
Here's the function that groups events by weekday:
The calendar worked last release. Before setting a single breakpoint, find the commit that broke it. git bisect does a binary search through history. You tell it one good commit and one bad one, and give it a command that exits 0 for good and non-zero for bad. A failing test is the perfect command:
Eleven commits, four test runs. The first bad commit is a one-line "refactor" that swapped a working initializer for new Array(7).fill([]). That's the version control domain criterion for Find a regression with bisect: "identifies the commit that introduced a bug."
Bisect tells you where. It doesn't tell you why. The diff looks harmless, which is exactly why it got merged.
The print-debugging instinct is to log the output:
Every bucket has both events. So the day index must be wrong. Add another print:
The indexes are right. Each event is pushed into one bucket, yet each bucket ends up holding both events. The prints contradict each other, and the next move is guessing.
Set a breakpoint on the push line and run the failing test under the debugger. In VS Code, a launch configuration for Vitest looks like this:
Execution stops before the first push. Open buckets in the Variables panel: seven empty arrays. Press Step Over once. All seven buckets now have length 1.
One push changed seven arrays. That isn't a grouping bug. It means the seven slots aren't seven arrays. Add a watch expression to confirm:
Array.prototype.fill puts the same value in every slot. When that value is an object, every slot holds a reference to one array. The fix creates a new array per slot:
The debugger didn't make us smarter. It showed us the state at the instant it changed, including the thing we hadn't thought to print: one action touched every bucket. That observation is the bug.
The same discipline applies when an AI assistant suggests a fix. A model can propose changing getDay() to getUTCDay(), and that won't fix anything. A troop who has stepped through the function knows why.
An engineer who can only print-debug is fine until the bug is in code they didn't write, in a process they can't easily restart, or in state they didn't think to log. Those are the bugs that take a team a week. We'd rather troops meet them here, with a mentor nearby, than on their first on-call rotation.
Next in the series: Fix the Flaky Test at Its Cause, where the bug is in time itself.
Vets Who Code is free for every troop, and it stays that way because people like you keep it running. If this post was useful, Donate or sponsor us on GitHub.
Vets Who Code is a free, remote software engineering accelerator for U.S. veterans, service members and spouses. If you know one who's ready to become a software engineer, send them this post and tell them to Apply. We'll take it from there.
31860 Sandy Plains Road, Ste 204 PMB 206
© 2026 Vets Who Code — All Rights Reserved
Vets Who Code is a registered 501(c)(3) nonprofit — EIN 86-2122804. Donations are tax-deductible to the fullest extent allowable under the law.
访问原文 返回搜索 https://vetswhocode.io/blogs/debug-by-stepping-not-by-printing
本页为82搜索生成的网页快照,内容来自站内索引;演示数据的原文链接仅作示例。