嘿，朋友们！ 我把所有东西都切换到深色模式了……现在打开白色页面感觉就像直视太阳🌞😵 不管怎样，我是@nyaomaru，一名前端工程师！ 你们最近和AI相处得怎么样？ 我过得很好，我们基本上已经是好朋友了。 曾经对自己说过： “嗯，暂时这样就可以了……” “我稍后会重构的……” 我们都积累了那些"暂时就这样"的时刻，对吧？ 这次，让我们来谈谈这些债务是如何堆积起来的，以及从实际的日常工程角度来看，真正需要付出什么来偿还它们。 让我们开始吧！
💸 什么是技术债务？
我们不是采用战略性的长期实现，而是堆积战术性的短期实现。 这导致了复杂、难以维护的代码和沉重的认知负担。 之所以被称为"债务"，是因为如果不去偿还，利息（额外负担）会不断增长。
例子：
“我暂时就这样写吧……虽然我知道应该正确地做。哦，好吧，只是暂时的！” “我不完全理解这段代码，但它能工作，所以我会复制粘贴并发布。只是暂时的！” “为了赶上截止日期，我们会跳过编写测试。只是暂时的！”
每个"只是暂时的"都会累积起来。短期收益，长期痛苦。
🧠 技术债务的现实
我理解。 没有人想写充满债务的代码。没有人是故意偷懒。有时候，压力是真实存在的。
初创公司需要快速发布，即使以积累债务为代价，以求生存。 大公司需要跟上竞争、截止日期和市场压力。
你尊重团队成员的工作。 截止日期是真实的。 有时候你只是想走捷径。 然后你告诉自己：“所以这是没办法的！” 但正是在这个时候，债务开始堆积。 问题是：以后谁来清理？ （是的，我只是想引用：“如果你放弃了，游戏就结束了。"）
🚨 为什么这是个问题？
到目前为止，你可能会想：“好吧，但那又怎样？” 以下是它在实践中造成伤害的原因：
- 新功能变得更难添加
- 新成员难以理解代码
- 调试和修复需要更长时间
- 警报占用你的时间
- 库更新变得不可能
简而言之：维护和操作变得痛苦。
🧱 更难添加功能
看似小的改动隐藏着大规模重构的需求。 不断延迟清理，债务就会呈指数级增长。
🧭 新成员更难上手
没有文档或类型，新来者会问：
“为什么这里是any类型？” “这两个函数有什么区别？” “API响应与代码不匹配——这是怎么工作的？”
入职流程拖延数月，生产力受到打击。
🐌 调试变慢
过时的代码和库会减慢构建、部署和本地测试的速度。 例子：
- 每次部署后手动验证
- 损坏或不可靠的E2E测试
- 组件测试不可预测地失败
很快，没有人信任测试，所以一切都要花两倍的时间。
🔔 无尽的警报
Sentry/Datadog用"无法读取未定义的属性"淹没你。 这些需要紧急响应，所以你最终只能打地鼠，而不是解决根本原因。
🧟 库更新变得不可能
依赖项失控地蔓延。 等到你需要更新时，风险已经太大。到处都是冲突，需要太多努力，损失太多时间等等…… 这就是遗留代码怪物的诞生方式。
☠️ 最终结局
最终，大胆的更改变得不可能。 你被困在一个巨大、脆弱的泥球中。 性能下降。客户转向更新的产品。 有才华的工程师因沮丧而离职。 但另一方面：如果你采取行动，你可以保护你的团队、你的产品和你的未来。
🛠️ 那么，我们能做什么？
债务不能一次性还清。 这很痛苦，但最快的途径是稳步偿还。 完全重写可能听起来很诱人，但这通常是一场赌博。 没有银弹。 以下是一些实际步骤：
- 定期进行小的重构
- 添加测试和文档
- 让债务可见并作为团队跟踪
- 避免过于紧张的时间表
- 提高"可接受质量"的基准
🧼 重构，即使是小东西
注意到一个any类型？ 看到一个可以通过提前返回简化的函数？ 发现重复的代码？ 在你在那里的时候修复它。小而稳定的清理最重要。
📑 添加测试和文档
测试提供信心。 文档（即使是一行"为什么"的注释）可以节省未来开发人员数小时的困惑。 把文档看作给你未来队友的一封信。
📋 让债务可见
如果团队对什么算作"债务"没有共同的理解，问题只会增长。 使用ESLint规则、编码指南和可见的"债务票据”。 债务不仅仅是你一个人的问题——作为团队共同承担。
🕰️ 避免过度紧张的时间表
紧迫的截止日期迫使草率的代码进入生产环境。 这些债务会持续数年。 为小的重构留出缓冲时间。 这是保持系统可持续性的方法。
📏 提高基准
一些组织强制执行严格的类型、完整的测试覆盖率和定期重构作为基准质量。 其他组织则满足于"只要它能运行"。 即使设置简单的规则，如：
- 不要忽略lint错误
- 总是编写测试
- CI/CD必须运行lint +测试
……也能产生巨大的差异。
🎯 最后思考
债务会追上你。 但稳定的偿还能让你安全。 不要完全懈怠——你未来的自己（和你的团队）会感谢你。 小额还款是最强的策略。
✍️ 后记
感谢阅读！ 老实说，这是我写给过去的自己的提醒。 如果忽视债务，它会消耗你。 但如果处理得当，它甚至可以成为盟友。 如果你的团队能减少哪怕一点点"暂时就这样"的心态，那就是胜利。 我很快会写更多关于实际债务偿还策略的内容。 敬请关注！
接下来
接下来，我将深入探讨技术债务实际上是如何形成的：从结构的角度。 我们将通过实际例子（使用Vue，但思想适用于React等）来看"暂时就这样"的决定如何滚雪球：
- 当原子设计在增长和速度下崩溃时
- “可重用"UI如何模糊为领域特定组件
- 清晰的边界：ui/ vs features/ 以及为什么它们重要
- 实际保障：命名、目录规则和CI检查
如果你曾经发现atoms/慢慢吸收了业务逻辑……这是为你准备的。 敬请关注！
✂️ 这就是要点！
技术债务不会一夜之间出现。它通过小的"就这一次"妥协悄悄潜入。 如果不加控制，结构崩溃，分类失效，甚至"原子"最终也会隐藏业务逻辑。 如果这听起来很熟悉，别担心：你并不孤单。 我很想听听你的团队是如何处理结构性债务的——你尝试过规则、CI检查或设计大修吗？ 在评论中分享你的想法，或分享你自己的战争故事。 欢迎反馈！🙌