编程与软件工程martinfowler.com编辑精选
技术债务
Technical Debt
2009 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Martin Fowler 对“技术债”这一由 Ward Cunningham 提出的经典隐喻的阐释：为了短期进度而走捷径，就像欠下债务，日后需要用额外开发成本来“偿还利息”。文章讨论了技术债的合理性与危险性，并强调关键在于是否有意识地承担并制定偿还计划。
为什么经久不衰：技术债是软件工程中最常用的沟通隐喻之一，十年间两次登上 HN 首页，说明它至今仍是团队讨论代码质量与业务取舍的核心框架。
HN 评论精选
技术债必须是有意识的、有偿还计划的权衡，低质量代码和遗留代码不应混为一谈。
我的唯一异议是：负债通常是有意识的选择。技术债应是做出务实决策的代价，是挥之不去的权衡。糟糕的架构决策或低质量代码不是技术债，只是被制度化的后果；遗留代码也不是技术债——它在当时是对的。真正存在的是“知识债”：工程师更替后，代码库中曾经直观优雅的部分对新员工完全陌生。要确立技术债，你必须定义偿还计划并留下有问责的记录，而不是把所有看着不顺眼的东西都算进去。MVP 同理，是有意识承担产品债的选择。
ljm查看英文原文
My only bone of contention is that taking on debt is usually a conscious choice. Technical debt to my mind is the price of making a pragmatic decision, it’s the trade-off that lingers. Making poor architectural decisions or writing poor quality code isn’t tech debt. They are just institutionalised consequences. The way the world now works. Legacy code isn’t tech debt either: it was right for the time. What you have instead is knowledge debt as engineers turn over, and the once intuitive and elegant parts of the codebase are utterly alien to the new hires who learned their craft in a totally different way. This isn’t tech debt because engineers can’t intuitively anticipate the business’s future hiring decisions, particularly when those are made independently of the team. If you want to establish tech debt you have to define the schedule to pay it off and there should be some record of that work somewhere, with accountability attached. It is not merely the accumulation of things you don’t like the look of or find hard to work with. Similarly, I think MVP is a conscious choice to incur product debt because it is far too risky and irresponsible to go all-in with your perfect vision right off the bat. You want your initial buy in and a chance to bail out or pivot before all is lost. Edit: as an example that comes to mind, a bank running on COBOL doesn’t have tech debt unless their COBOL engineers are aware of their missed opportunities. If they think COBOL is no longer fit for purpose, it’s not debt, it’s time to reinvest.
技术债的权衡取决于软件的寿命和迭代模式，并非所有场景都值得偿还。
我在 Windows 团队开始职业生涯，作为平台方，API 一旦发布就基本永久存在，所以技术债是规划的核心。后来加入 Netflix，我花数周重构流媒体代码清理技术债，经理却让我尽快收工，并解释他们团队的价值观：1) 大多数代码每 2-3 年会被重写；2) 对不常重写的代码，保留久经考验的代码胜过偿还技术债。请记住技术债并不适用于所有软件。
rsweeney21查看英文原文
I cut my teeth as a developer on the Windows operating system. Because we were a platform, we had learned that when we shipped an API it became more or less permanent. So technical debt was a huge part of our planning and thought process. When I joined Netflix I was assigned to add DASH support to the Silverlight web player. I spent weeks working on the new architecture, refactoring the streaming code, etc. One day my manager stopped by my desk and said that "I needed to wrap it up. It was taking too long." I was still weeks away from being done. I explained to that I was cleaning up a ton of technical debt and that's why it was taking so long. He explained to me that they had different values on his team. 1. Most code will be rewritten every 2 to 3 years. 2. For code that doesn't get rewritten often, preserving battle tested code trumps paying down technical debt Just remember that technical debt doesn't apply to all software.
偿还技术债要有限度：防御性工作占比过高会在组织内失去支持。
《Team Geek》中有个实用法则：把工作分为“进攻性”（用户可见的新功能）和“防御性”（重构、重写、数据迁移等维护长期健康的工作）。防御性工作至关重要却没有政治回报，做太多会让产品看起来停滞不前。团队应遵守的准则是：无论技术债有多少，防御性工作不要超过三分之一到一半的时间和精力，再多就是政治自杀。
kashyapc查看英文原文
[I recall posting this here in the past, but worth re-posting.] The "handy rule" from the book Team Geek -- the newer edition is called Debugging Teams[1]. It's from chapter "Offensive versus Defensive work": [...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migra- tion, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.” We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide. [1] http://shop.oreilly.com/product/0636920042372.do
技术债难以向非工程师解释，因为只有软件这类“前序产出是后续输入”的领域才会自我累积成本。
我一直在想为什么非工程师很难理解技术债。我认为原因是：A) 它只影响真正长期存在、有状态的过程——软件工程中前一阶段的产出是下一阶段的输入；B) 日常生活中这类过程很少。销售赶进度不会让下次打电话变慢，厨师偷工减料不会让以后做饭变慢，但软件里仓促实现功能 A 确实会让后续功能开发变慢，因为未来的功能建立在之前的代码之上。
akeefer查看英文原文
I've thought a lot about why technical debt seems to be such a hard concept for non-engineers to grasp; certainly given how few business people or managers seem to understand it, it clearly must be difficult. I think it's because A) it only affects a truly long-lived, stateful process, like a software (or many other types of engineering process) where the output of one phase is the input to the next phase and B) there just aren't that many sorts of processes that occur in ordinary life. Sure, in any field you can screw up in such a way that it hurts you in the future by damaging your reputation or annoying your customers, or make bad technical investments that turn out to cost you. But in engineering disciplines, doing your core activity (engineering) poorly can hurt your ability to keep doing your core activity (engineering) in the future. If you're in sales and you cut corners with one client, it doesn't make your phone calls take longer. If you're in a restaurant and you cook things too fast or cut corners on ingredients, it doesn't make your future cooking take longer. If you're a doctor and you're too hasty and mis-diagnose a patient, it doesn't make your future surgeries and checkups take longer. But in software, if you're too hasty adding feature A, it does make your future features take longer to develop. And that's because in software, your future features are built on the previous ones, whereas with sales, cooking, or medicine the duration of any given prospect/customer/patient is relatively short-lived and finite. That's my best theory as to why it's so hard for non-engineers to understand.
历次讨论
同类还值得读
开源应用架构
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编辑精选