问题标签 [technical-debt]

您是否积极管理软件开发项目的技术债务，如果是，您是如何做到的？

通过 Martin Fowler和Steve McConnell的技术债务

YAGNI（你不需要它）通过维基百科

BDUF（前面的大设计）通过维基百科

更新：为了澄清这个问题，我想我也可以这样陈述并保持我的意思：

“作为一名敏捷实践者，您如何在每次迭代中在“快速和肮脏”（在尝试遵守 YAGNI 时无意冒着技术债务风险）和过度工程（BDUF）之间找到适当的平衡？

在您的实践中，您如何有效地跟踪和管理技术债务？

是否有您使用的特定指标，例如SLOC？

您如何向利益相关者和管理层直观地展示您的结果？

你在这个过程中看到了什么好处？

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

我是 ruby​​ on rails 的忠实粉丝，它似乎融合了许多 Web 应用程序编程技术的“最热门”。在我看来，约定优于配置尤其是一个巨大的胜利。

然而，我也有一种感觉，我得到的一些便利是以需要在未来偿还的技术债务为代价的。并不是我认为 ROR 又快又脏，因为我认为它在许多情况下包含了许多最佳实践和良好的默认选项。然而，在我看来，这还没有涵盖一些东西（特别是框架中几乎没有对安全性的直接支持，而且我看到的插件质量参差不齐）。

我不是在这里寻找宗教观点或激战，但我很想知道社区对 Rails 需要改进的领域的看法，和/或 Rails 用户需要自己注意的事情，因为框架不会牵着他们的手引导他们做正确的事。

虽然最近的Coding Horror 博客文章不是我第一次听说这个概念，但当我阅读它时，我忍不住将它应用到我自己的项目中。

我正在处理的代码库是一个正在进行的项目，现在大约有 3 年了，项目早期阶段的大部分代码是由开发人员编写的，他们几乎没有监督，这导致了很多代码重复、性能不佳等。在与管理层的讨论中，我试图说明有几个关键组件迫切需要重构，这样做可以在未来的迭代中节省大量时间和添加新功能时的麻烦并修复这些关键领域的错误。虽然他们似乎相信我重构这些组件会很好，但他们不想给我这样做的余地。请注意，我不是在谈论对整个代码库的重写或任何戏剧性的事情，只是对几个核心领域的重写，这将花费大约 2-3 周的时间。

那么问题来了，作为一名开发人员，您如何向您的经理推销这些领域需要解决的问题，并提出商业案例以便现在有时间解决这些问题，而不必只是在这里和那里逐步改进？

当出现新版本的框架或语言（例如 .NET 3.5、SQL2008）时，人们在何时采用/升级时采取什么方法？

一般来说，开发人员会尽快说（他们希望在他们的简历中提供，从管理的角度来看，给他们想要的东西会激发他们的动力），但在商业上通常很少有激励（很少有客户需要最新版本）并且从成本的角度来看（重新测试，培训）通常有一个抑制因素。

我特别想到了多年来存在和发展的“正在进行的”系统和项目（例如在软件公司中），而采用“新项目使用新技术”的方法是行不通的。

人们是否受到特定需求的驱动（需要使用新功能，潜在或现有客户要求支持），他们是否正式评估它（在这种情况下，标准是什么）或者他们是否将升级作为例行公事（在这种情况下 - 前沿与前沿）？

人们是否认为不使用最新版本的东西应该被视为技术债务并进行管理？

或者“如果它没有坏就不要修复它”是一种有效的方法吗？

我日常使用的网站也有其不足之处，我们经常做出设计决策以“立即解决”，并打算在以后解决这些问题。

我发现花时间实际回去修复它们，更不用说记住待办事项的完整列表了，充其量是具有挑战性的。

您能否推荐任何有助于有效管理技术债务的工具、资源或技巧？

我们计划在 2010 年完成一些功能性交付，但我们也有技术议程（架构重构、整合、升级平台）。有关将这些内容包含在路线图中的最佳方式的任何建议，以帮助企业了解它们为何重要。

一个选择就是说相信我们，因为这是保持一切健康的正确做法，但如果可能的话，我希望有更好的可视化

我目前正在使用一个相当旧的产品，该产品背负着过去糟糕的程序员和糟糕的开发实践带来的大量技术债务。我们开始变得更好，技术债务的产生已经大大放缓。

我已经确定了应用程序中状况不佳的区域，并且我可以估算修复这些区域的成本，但我很难估算投资回报 (ROI)。

代码将更容易维护，并且将来更容易扩展，但我怎样才能在这些上放一个美元数字呢？

一个好的开始看起来像是回到我们的错误跟踪系统并根据与这些“坏”区域相关的错误和功能估算成本。但这似乎很耗时，并且可能不是价值的最佳预测指标。

过去有没有人做过这样的分析并对我有什么建议？