技术债务（至少）有两种方式进入项目。 第一个是有意识的决定。 有些问题不值得预先解决，因此有意识地允许它们作为技术债务累积。 第二是由于无知。 从事该项目的人员不知道或没有意识到他们正在承担技术债务。 这个问题涉及第二个问题。 您在项目中是否存在一些技术债务，这些债务原本是微不足道的，可以排除在外（“如果我早知道……”），但一旦将它们嵌入到项目中，它们的成本就会急剧增加？
There are (at least) two ways that technical debts make their way into projects. The first is by conscious decision. Some problems just are not worth tackling up front, so they are consciously allowed to accumulate as technical debt. The second is by ignorance. The people working on the project don't know or don't realize that they are incurring a technical debt. This question deals with the second. Are there technical debts that you let into your project that would have been trivial to keep out ("If I had only known...") but once they were embedded in the project, they became dramatically more costly?
发布评论
评论（11）
完全忽视安全问题。
跨站点脚本就是这样的一个例子。 它被认为是无害的，直到您在管理界面中弹出
警报（'你好！'）（如果您幸运的话 - 脚本也可能会默默地复制管理员有权访问的所有数据，或提供恶意软件给您的客户）。然后您需要昨天修复 500 个模板。 仓促修复会导致数据双重转义，并且无法堵住所有漏洞。
Ignoring security problems entirely.
Cross-site scripting is one such example. It's considered harmless until you get
alert('hello there!')popping up in the admin interface (if you're lucky - script may as well silently copy all data admins have access to, or serve malware to your customers).And then you need 500 templates fixed yesterday. Hasty fixing will cause data to be double-escaped, and won't plug all vulnerabilities.
将日期存储在本地时区的数据库中。 在某些时候，您的应用程序将迁移到另一个时区，您就会遇到麻烦。 如果你最终遇到了混合的日期，你将永远无法理清它们。 只需将它们存储在 UTC 中即可。
Storing dates in a database in local timezone. At some point, your application will be migrated to another timezone and you'll be in trouble. If you ever end up with mixed dates, you'll never be able to untangle them. Just store them in UTC.
其中一个示例是以不支持 Unicode 的模式运行数据库。 它一直有效，直到您被迫在数据库中支持 Unicode 字符串为止。 迁移路径并不简单，具体取决于您的数据库。
例如，SQL Server 具有固定的最大行长度（以字节为单位），因此当您将列转换为 Unicode 字符串（NCHAR、NVARCHAR 等）时，表中可能没有足够的空间来保存已有的数据。 现在，您的迁移代码必须做出有关截断的决定，否则您必须完全更改表布局。 不管怎样，这比仅仅从所有 Unicode 字符串开始要工作得多。
One example of this is running a database in a mode that does not support Unicode. It works right up until the time that you are forced to support Unicode strings in your database. The migration path is non-trivial, depending on your database.
For example, SQL Server has a fixed maximum row length in bytes, so when you convert your columns to Unicode strings (NCHAR, NVARCHAR, etc.) there may not be enough room in the table to hold the data that you already have. Now, your migration code must make a decision about truncation or you must change your table layout entirely. Either way, it's much more work than just starting with all Unicode strings.
单元测试——我认为如果不及时编写测试就会招致难以弥补的巨大债务。 虽然我是 TDD 的粉丝，但我并不关心你是在实现代码之前还是之后编写测试......只要你保持测试与代码同步即可。
Unit Testing -- I think that failing to write tests as you go incurs a HUGE debt that is hard to make up. Although I am a fan of TDD, I don't really care if you write your tests before or after you implement the code... just as long as you keep your tests synced with your code.
没有使用 javascript 框架启动 Web 项目并手动实现已经可用的东西。 维护手写的 javascript 变得非常痛苦，我最终把它全部撕掉并用框架重做。
Not starting a web project off using a javascript framework and hand implementing stuff that was already available. Maintaining the hand written javascript became enough of a pain that I ended up ripping it all out and redoing it with with the framework.
我真的很挣扎这个问题，试图平衡 YAGNI 和“我已经被这个烧伤了”太频繁了”
我对每个应用程序进行审查的事项清单：
其他可能产生技术债务的领域包括：
我确信还会有其他人...
I really struggle with this one, trying to balance YAGNI versus "I've been burned on this once too often"
My list of things I review on every application:
Other areas where technical debt can be incurred include:
I'm sure there will be others...
可扩展性——特别是数据驱动的业务应用程序。 我不止一次地看到一切似乎都运行良好，但是当 UAT 环境最终支持接近生产的数据库表大小时，事情就开始左右下滑。 当数据库基本上将所有行保存在内存中时，在线屏幕或批处理程序很容易运行。
Scalability - in particular data-driven business applications. I've seen more than once where all seems to run fine, but when the UAT environment finally gets stood up with database table sizes that approach productions, then things start falling down right and left. It's easy for an online screen or batch program to run when the db is basically holding all rows in memory.
在以前的一家公司，他们使用并强制使用 COM 来处理不需要的东西。
另一家拥有 C++ 代码库的公司不允许使用 STL。 （WTF？！）
我参与的另一个项目仅使用 MFC 进行集合 - 不涉及 UI。 那很糟糕。
当然，这些决定的影响并不大。 在两种情况下，我们无缘无故地依赖可怜的 MS 技术，而另一种情况则迫使人们使用更糟糕的泛型和集合实现。
我将这些归类为“债务”，因为由于前期的愚蠢决定，我们必须在项目后期做出决定和权衡。 大多数时候我们必须解决这些缺点。
At a previous company they used and forced COM for stuff it wasn't needed for.
Another company with a C++ codebase didn't allow STL. (WTF?!)
Another project I was on made use of MFC just for the collections - No UI was involved. That was bad.
The ramifications of course for those decisions were not great. In two cases we had dependencies on pitiful MS technologies for no reason and the other forced people to use worse implementations of generics and collections.
I classify these as "debt" since we had to make decisions and trade-offs later on in the projects due to the idiotic decisions up front. Most of the time we had to work around the shortcomings.
虽然并非所有人都同意，但我认为技术债务的最大贡献者是从任何类型的应用程序的界面开始并在堆栈中向下工作。 我逐渐了解到，通过实现 TDD 和 DDD 的组合，偏离项目目标的可能性会更小，因为您仍然可以开发和测试核心功能，而界面则成为锦上添花。
诚然，这本身并不是技术债务，但我发现自上而下的开发更像是一个开放的大门，它会导致未经深思熟虑的决策——所有这些都是为了做一些“看起来很酷”的事情”。 另外，我知道并不是每个人都会同意或有同样的感觉，所以你的里程可能会有所不同。 团队动力和技能也是这个方程式的一部分。
While not everyone may agree, I think that the largest contributor to technical debt is starting from the interface of any type of application and working down in the stack. I have come to learn that there is less chance of deviation from project goals by implementing a combination of TDD and DDD, because you can still develop and test core functionality with the interface becoming the icing.
Granted, it isn't a technical debt in itself, but I have found that top-down development is more of an open doorway that is inviting to decisions that are not well thought out - all for the sake of doing something the "looks cool". Also, I understand that not everyone will agree or feel the same way about it, so your mileage might vary on this one. Team dynamics and skills are a part of this equation, as well.
陈词滥调是，过早的优化是万恶之源，这对于微优化来说当然是正确的。 然而，在设计层面上完全忽视性能显然很重要的领域可能是一个坏主意。
The cliche is that premature optimization is the root of all evil, and this certainly is true for micro-optimization. However, completely ignoring performance at a design level in an area where it clearly will matter can be a bad idea.
预先没有一个有凝聚力的设计往往会导致这种情况。 如果您花时间经常重构，您可以在一定程度上克服这个问题，但大多数人都会对不符合他们不断变化的需求的整体设计进行抨击。 这可能是您所寻找的更普遍的答案，但确实往往是技术债务的更常见原因之一。
Not having a cohesive design up front tends to lead to it. You can overcome it to a degree if you take the time to refactor frequently, but most people keep bashing away at an overall design that does not match their changing requirements. This may be a more general answer that what your looking for, but does tend to be one of the more popular causes of technical debt.