如何减少技术债务而获得报酬？

我目前在一家技术含量很少的小型公司工作。我是其中之一的唯一开发者。大约一年前，我获得了该产品的旧版本并开始“支持”它。

客户只谈论新功能，业务价值和其他类似的功能。问题是，尽管代码是用C＃编写的，但它是过程性的。没有抽象，仅在Visual Studio需要它们的地方才使用类-例如表单。这些类的实现确实很糟糕，并且代码很难维护。

这些年来，我花费自己的时间进行重构。在最新版本中，有一些漂亮的抽象等。我不得不从头开始重新实现许多组件，我真的觉得向这些组件添加新功能或更改行为要比其他组件容易得多。

问题是，我花自己的时间。我非常喜欢结果，但我不喜欢每天工作12个小时。您去过类似情况吗？我应该怎么做？我已经尝试过讨论它，但仍然没有成功。

当我们决定实现需要对遗留代码进行大量更改的新功能时，我只是感到害怕。这可能会让客户感到震惊：为什么您需要8个小时来更改这些图标？客户只是不在乎我需要更改代码中的500个位置。我还应该首先找到所有这500个地方。

有任何想法吗？

步骤1：停止无偿加班。

您已经对客户和经理进行了一年的培训，使他们相信当前的发展速度是可以预期的。这就是为什么他们不了解为什么“简单”的事情可能需要一整天才能完成的部分原因。您不需要将他们当作人质并试图伤害项目。但是，您需要说明他们的期望过高，您可能需要其他开发人员，或者在截止日期之前需要更多时间。请特别向您的经理提及您一直无偿加班，并计划不做那么多。即使您将其缩减为9小时工作日，也会注意到差异。如果您的经理问您为什么不完成您的工作，您可以指出一个事实，那就是要警告他，事实就是这样。

步骤2：做笔记

仅仅因为您没有时间来完成工作，并不意味着您无法（希望）完成工作时变得更加轻松。跟踪有关修改代码的想法，并在会议上提出来，以便其他人知道您的问题。最终，您会遇到一个缓慢的过程，否则人们将开始理解您的顾虑具有价值。到了这个时候，您将已经有了一些有关做什么的基本想法，而不会因为一阵子没看一段代码而干dry。

代码真的很难维护。

这是您管理的方式。证明“仅”修复错误和添加新功能的成本要高于重构和重写代码的成本。

例如，如果使用当前代码添加新功能需要2周时间，然后需要大量时间（例如每周1天）进行维护，则表明通过一周的重构，您可以在1 1/2的时间内完成开发数周，但您可以将维护减少到每月1天（或更少）。这些数字将表明您的工作在中长期内具有成本效益，即使存在短期成本也是如此。

尽管公司可能不喜欢现在花这笔钱，但他们会看到潜在的好处要大得多-即您将在更少的时间内生成更多代码，从而提高生产力，并且代码质量更高。

应用童子军规则：每次触摸代码时，请使其代码保持整洁（即减少技术债务）。

给你所有的估计时间。然后，神奇的是，随着时间的流逝，技术债务将消失，您将为此而获得报酬。

这种方法比明确尝试花费更多时间（从而说服客户/经理支付）来偿还技术债务要容易得多。它给您带来更专业的感觉和“做得很好”。最后，即使他们不太了解它是如何发生的，从长远来看，您的客户和经理也会感谢您。

这或多或少是维护编程的可悲现实。您受制于要分配给您维护的东西，如果支付账单的人不想为自己认为是无益的变更付出代价，那么这些变更往往就不会完成。

如果您想为这些变更提供资金，那么即使是最简单的更新，也要保留所有必须更改的地方的日志。进行一些更改后，请与您的经理讨论该日志。如果您可以记录下来，则有一个机会（虽然很渺茫），拥有钱包字符串的人会意识到，从长远来看，现在清理代码实际上会更便宜，因为这会使将来的更改变得更便宜。

预期使用此产品的时间越长，您出售该产品的机会就会增加。如果产品故障很可能给客户造成公共关系问题或使客户蒙受损失，赔率也会增加。

除非如此，否则您将学到什么，然后以更少的维护成本转到另一个位置。

您需要向管理层展示重构和改进产品如何使公司受益。

只要代码可以工作，客户就不太在乎代码是美观还是丑陋，管理层也不会急于向客户解释他们已经付款的东西设计不好，执行不力。同时，管理人员不会急于吃掉不能以某种可见（可计费）方式改进产品的开发时间。

所以...您必须说服管理层，您提出的更改将帮助公司：

• 向他们展示更好的体系结构将使您能够更快地添加新功能。
• 向他们解释，沿着当前的道路继续前进，他们将自己画在一个角落。
• 给出更改示例，这些更改在当前系统中进行起来非常昂贵，但是通过更好的设计将变得既简单又便宜。
• 跟踪维护旧代码与添加实用功能所花费的时间。-帮助他们向现有客户和未来客户说明，尽管现有系统相当不错，但新的，现代化的体系结构将带来许多重大的改进，更好的可靠性等等。
• 减轻与您建议的更改相关的风险。管理者不愿承担风险，对现有系统进行全面更改似乎具有固有的风险。
  • 根据成本和收益优先考虑各个组件的现代化，并确保管理层同意您的优先事项。
  • 使用单元测试来帮助确保现代化的组件将与其余的旧代码兼容。
• 跟踪现代化工作的进度。尽您所能，立即显示收益，但要提醒所有各方，还有更多工作要做。

您可能没有意识到，但是Johnny Cash预测了重构的趋势，并写了一首歌，讲述了重构现有大型代码库的最佳方法。

当然，他必须将其包装在汽车的隐喻中，这样他的听众才能与之相关。

“一次一件”-Johnny Cash

看来您可以向客户收取更改“应该”花费的时间，但从长远来看仍会提前。

如果您喜欢清理代码（似乎至少做了一点），请继续进行下去，但不要因此而烦恼。这对您，您的公司或其他客户没有任何好处。

确保您的管理层和与客户合作的任何人都知道代码的状态不佳，以便他们可以做出明智的决定-仅仅因为您拥有该代码并不意味着您应该就此制定业务决策，如果他们不知道代码的问题，那么他们就无法完成工作。

尽管客户的应用程序有一些技术债务，但是请不要忘记，它们可能会收取一些折扣。他们可能没有意识到这一点，但是当您采用最低出价时，就会发生这种情况。

他们需要决定是否要为功能更改全额支付还是不做这些更改。这是他们的选择。您可以让他们做出决定或继续免费工作。您可以尝试提及您所做的清理工作，并为完成的工作提供一些折扣。再次，这是他们的选择。

我要采用的方法是从向老板解释技术债务的概念开始，以确保他们得到了。从底线，业务角度进行处理。每当他们要求一个新功能时，产品中累积的技术债务都会影响您的效率，因此，由于这些债务，每个功能的成本都会有所增加。

一旦他们了解了您在说什么，就尝试花一些时间来减少技术债务。在我公司，我们成功地为每个技术人员申请了10％的时间，以减少技术债务。

一旦有时间来进行此操作，请确保您确实使用了它（不要仅仅加班10％来做，要坚持使用枪支）。创建技术债务项目目录并确定优先级，然后开始削减。您必须一次吃一口大象。

并且不要忘记考虑使用更好的工具。Resharper是插入Visual Studio的出色重构工具。