是否存在不值得产生的具体“技术债务”？

Question

技术债务可以（至少）有两种方式进入项目。首先是有意识的决定。有些问题不值得提前解决，因此有意识地允许他们积累技术债务。第二是无知。从事这个项目的人不知道或者没有意识到他们正在承担技术债务。这个问题涉及第二个问题。您是否存在技术性债务，这些技术债务可能会让您无法避免（“如果我只知道......”），但一旦将它们嵌入到项目中，它们的成本就会大大增加？

Answer 1

完全忽略安全问题。

跨站点脚本就是一个这样的例子。在您在管理界面中弹出alert('hello there!')之前，它被认为是无害的（如果您很幸运 - 脚本可能会默默地复制管理员可以访问的所有数据，或者向您的客户提供恶意软件）。

然后你需要修复昨天的 500个模板。仓促修复会导致数据被双重转义，并且不会堵塞所有漏洞。

Answer 2

以本地时区在数据库中存储日期。在某些时候，您的应用程序将迁移到另一个时区，您将遇到麻烦。如果你最终得到混合日期，你永远无法解开它们。只需将它们存储在UTC中。

Answer 3

这方面的一个示例是以不支持Unicode的模式运行数据库。它一直有效，直到您被迫支持数据库中的Unicode字符串。迁移路径非常重要，具体取决于您的数据库。

例如，SQL Server具有固定的最大行长度（以字节为单位），因此当您将列转换为Unicode字符串（NCHAR，NVARCHAR等）时，表中可能没有足够的空间来保存您已经存在的数据有。现在，您的迁移代码必须做出有关截断的决定，或者您必须完全更改表格布局。无论哪种方式，只需从所有Unicode字符串开始，它的工作要多得多。

Answer 4

单元测试 - 我认为在你去的时候没有编写测试会产生很难弥补的巨额债务。虽然我是TDD的粉丝，但是如果你在实现代码之前或之后编写测试，我真的不在乎......只要你的测试与你的代码保持一致。

Answer 5

不使用javascript框架启动Web项目并手动实现已有的东西。保持手写的javascript变得足够痛苦，我最终把它全部撕掉并用框架重做它。

Answer 6

我真的很挣这个，试图平衡YAGNI与“我曾经经常被焚烧”

我在每个应用程序中查看的内容列表：

1. 位置：
   1. 时区永远会变得重要吗？如果是，则以UTC格式保留日期/时间。
   2. 邮件/文字是否会被本地化？如果是，请外部化消息。
2. 平台独立？选择一个易于移植的实现。

可能产生技术债务的其他领域包括：

• 黑洞数据收集：一切都进入，没有任何事情发生。 （没有存档/删除旧数据的长期计划）
• 未能在应用程序生命周期内保持MVC或层间分离 - 例如，允许过多的逻辑进入View，这使得为移动设备或Web服务添加接口的成本更高。

我相信会有其他人......

Answer 7

可伸缩性 - 特别是数据驱动的业务应用程序。我不止一次看到所有似乎都运行良好，但是当UAT环境终于站起来接近生产的数据库表大小时，事情就开始向右和向左倾斜。当db基本上保存内存中的所有行时，可以很容易地运行在线屏幕或批处理程序。

Answer 8

在之前的一家公司，他们使用并强迫COM处理不需要的东西。

另一家拥有C ++代码库的公司不允许使用STL。 （WTF？！）

我参与的另一个项目仅使用MFC来收集 - 没有涉及UI。那太糟糕了。

这些决定的后果当然不是很好。在两种情况下，我们无缘无故地依赖于可怜的MS技术，另一种情况迫使人们使用更糟糕的泛型和集合实现。

我将这些归类为“债务”，因为我们不得不在项目后期做出决策和权衡，因为前面有愚蠢的决定。大多数时候我们不得不解决这些缺点。

Answer 9

虽然不是每个人都同意，但我认为技术债务的最大贡献者是从任何类型的应用程序的界面开始，并在堆栈中工作。我已经了解到，通过实施TDD和DDD的组合，偏离项目目标的可能性较小，因为您仍然可以开发和测试核心功能，并使界面成为结冰。

当然，它本身并不是技术债务，但我发现自上而下的发展更像是一个开放的门户，它正在邀请那些没有经过深思熟虑的决策 - 所有这一切都是为了做某事“看起来很酷”。此外，我知道不是每个人都会同意或对此有同感，因此您的里程可能因此而异。团队动力和技能也是这个等式的一部分。

Answer 10

陈词滥调是过早优化是所有邪恶的根源，对于 微 - 优化肯定也是如此。但是，在明显重要的区域完全忽略设计级别的性能可能是一个坏主意。

Answer 11

预先没有紧密的设计倾向于导致它。如果你经常花时间进行重构，你可以在一定程度上克服它，但大多数人都在抨击整体设计不符合他们不断变化的要求。这可能是您所寻找的更普遍的答案，但确实往往是技术债务更受欢迎的原因之一。