破窗理论
没人修复的小问题，会向团队传递出质量不重要的信号。
显示原始英文内容
Broken Windows Theory
Don't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired.
Takeaways
- If you let minor bugs and bad style slide, people assume quality doesn't matter, and they'll ship messier code.
- A clean, well-maintained codebase encourages engineers to keep it clean, whereas a chaotic codebase encourages corner-cutting and further degradation.
- Fix problems while they're small. Refactor destructive code, update outdated docs, to prevent a downward spiral of code health.
Overview
The Broken Windows Theory in software was popularized by the book The Pragmatic Programmer. In a city, a broken window left unfixed signals neglect and invites more vandalism. Similarly in code, an apparent bug or messy section left untreated can lead to more developers bypassing the process or introducing more mess.
The idea is that quality problems snowball if left unaddressed. For example, if a team routinely ignores failing tests or lets linters/errors slide during builds, developers get the message that it's okay to ship sloppy work. This accelerates code decay (also known as software entropy).
Conversely, if a team quickly fixes minor issues and maintains high standards, it creates a culture of quality.
Examples
Consider a codebase with a few obvious kludges, such as functions with // TODO: fix this hack comments that never get fixed. If newcomers see that, they may be more inclined to add their own hacks ("this project is full of hacks anyway..."). Or if there's a module with no tests (a "broken window" in a test-coverage sense), other modules might start losing tests too as discipline erodes.
On the opposite side, think of a project where maintainers aggressively fix style issues and simplify code whenever they spot a problem. By contributing to such a project, developers quickly learn to match that cleanliness.
Many teams have turned projects around by paying off technical debt and cleaning up code. Once things are polished, they find fewer new bugs are introduced because everyone is more careful.
Origins
The Broken Windows Theory comes from criminology (James Q. Wilson and George Kelling, 1982). In software, Andy Hunt and Dave Thomas applied it as a metaphor in The Pragmatic Programmer (1999). They argued for fixing minor problems promptly.
Jeff Atwood and others in blogs have also discussed this principle in the context of software project maintenance.
核心含义
一处坏掉的测试、混乱的命名或长期忽略的告警，会降低团队对质量问题的敏感度。问题越多，新增问题越容易被合理化，系统就会进入持续恶化的循环。
团队需要明确哪些问题必须及时修复，哪些可以记录并延后，同时让“修一扇小破窗”成为正常工作的一部分。
实践例子
持续集成中一个偶尔失败的测试无人负责，几周后大家都开始忽略红色构建，真正的回归缺陷也被淹没在噪声中。
来源与边界
破窗理论来自犯罪学和城市治理讨论，在软件中是一种类比。它不意味着每个格式问题都应阻塞交付，关键是避免没有标准、没有责任人的长期失控。