一个脏窗口如何拖垮整个代码库？开发者必须警惕的“破窗效应”

作者提米哥

你有没有遇到过这样的项目：

  • 第一天接手，发现有个函数命名是 get_data_from_api_v2_fix；
  • 第二天看到注释写着 // TODO: 重构这里，先凑合用，而这个 TODO 已存在 3 年；
  • 第三天想加个日志，结果发现根本没有统一的日志规范，有人用 console.log，有人写 console.error("xxx") 当 info 用……

别急着骂前人。这很可能不是「人的问题」，而是——破窗效应（Broken Windows Theory）在悄悄生效。

它不讲玄学，只讲信号：

一个没人修的小问题，就是在向所有人广播：“这里标准不高，凑合就行。”

一旦这条消息被团队（甚至你自己）接收到，更多“小妥协”就会自然发生——就像没人擦的白板、永远不关的 IDE 警告、从不运行的单元测试……它们本身不致命，但合起来，就是代码腐化的起点。

🔍 破窗在哪？三秒自查清单（开发者友好版）

  • ✅ 你的 Git 提交信息里，有没有大量 fix bug、update file 这类模糊描述？
  • ✅ package.json 里有没有一堆 ^1.2.3 版本号，却从不更新依赖？
  • ✅ CI 流水线里有没有几个长期失败但被“忽略”的测试用例？
  • ✅ 代码审查（PR）时，是否常跳过空格/缩进/命名风格等“小问题”，说“下次再统一”？

👉 这些，就是你代码库里的「破窗」——它们不报错，但正在悄悄降低团队的交付信心和新人上手速度。

🛠️ 怎么修？4 个可立刻执行的动作（无脑跟做）

  1. 今天就删掉一个“TODO 注释”
    找到最老的那个 // TODO:，花 15 分钟把它干掉（哪怕只是补个简单注释 + 改个变量名）。修的不是代码，是信号。

  2. 给你的 ESLint / Prettier 加一道“硬门槛”
    把格式检查接入 pre-commit（比如用 husky + lint-staged），让“不规范的代码根本提不了交”：
    bash
    # 示例：pre-commit 钩子配置（.husky/pre-commit）
    #!/usr/bin/env sh
    npm run lint:fix && git add . # 自动修复并暂存
    npx eslint --ext .js,.ts src/ --quiet --fix # 强制检查

    中文注释：每次 git commit 前自动格式化 + 检查，不通过就拦住——让“整洁”成为默认，而非选项。

  3. PR 模板里加一行强制项
    在 .github/PULL_REQUEST_TEMPLATE.md 里加上：
    “`markdown

  4. [ ] 我已检查：所有新增/修改的代码都符合团队 [编码规范链接]（含命名、注释、错误处理）
    “`

    别怕显得“较真”。这行勾选框，比 10 次口头提醒更管用。

  5. 每周五下午，留 30 分钟“破窗清扫时间”
    和团队一起，只做一件事：找一个最小、最无争议的“脏窗口”（比如某处重复的 console.log、某个没用的 import），集体 fix + 提交 + 合并。
    ✅ 做完后同步发条简短 Slack：✅ 本周破窗已修复：移除了 utils/date.js 中废弃的 formatOldDate() 函数

    这不是修代码，是在重刷团队的“质量基线”。

💡 为什么这么小的事，值得你动手？

因为：
– 技术债不会自己消失，但会自己繁殖 —— 一个临时方案催生三个新临时方案；
– 新人第一眼看到的不是架构图，而是 PR 评论里那句“建议改下命名”被点了 👍 却没执行；
– 你写的每一行“将就”，都在教大脑：“这里可以不认真。”

反过来也成立：
→ 你坚持一次 const 而非 var，
→ 你多写一行 @param {string} userId JSDoc，
→ 你把 if (x == null) 主动改成 if (x == null || x === undefined)，

这些动作本身耗时不到 10 秒，但它们持续向环境发射同一个信号：
“我们在这儿，认真写代码。”

而人，天生会跟随环境信号行动——不用喊口号，秩序自生。

直达网址：https://keeprule.com/en/blog/broken-windows-theory

作加

类似文章