如果您正在使用敏捷，其想法是始终进行增量重构，并且永远不会积累大量技术债务。话虽如此，如果您有一个敏捷团队正在接管具有大量技术债务的软件，那么您必须将其安置在某个地方。
你会去创建开发者用户故事吗？ 。例如 。
或者是否有其他清理此代码技术债务的最佳实践
【问题讨论】：
标签： agile
您的应用是内部应用还是有外部客户？如果客户为您在应用程序上的工作和支持付费，可能很难让他们在您建议的卡片上签字。
另外，根据您的第二张卡片创意，可能很难说出“完成”是什么。
针对您的问题的一种特定方法可能是缺陷驱动测试——这个想法是，当您收到错误报告并估计说要修复它的卡时，看看您可以同时添加哪些测试相似，但增加了覆盖范围。
您并没有特别要求提供有关如何让您的项目接受测试的技术细节，但是一旦您开始实际操作，这本书就会非常有帮助：Working Effectively with Legacy Code
【讨论】：
应该区分工程实践和技术债务。我将测试驱动开发和自动化测试视为实践。
采用瀑布团队构建的代码资产后，这些资产没有进行自动化单元、功能或性能测试。当我们承担软件资产的责任时，我们对产品负责人进行了敏捷培训，并告诉他们我们将使用的实践。
一旦我们开始使用这些做法，我们就会开始识别技术债务。随着技术债务的确定，技术故事卡由产品所有者编写并放置在产品待办事项列表中。开发人员和测试人员使用 XP 工程实践（TDD、自动化测试、结对编程等）估计所有工作。这些实践通过 TDD、自动化功能和性能测试确定了代码中的脆弱性。特别是，通过自动化性能测试和分析发现了一个重要的性能问题。债务是如此之大，以至于我们估计修复需要 6 次迭代。我们通知产品负责人，如果开发了新功能，由于应用程序性能不佳，用户群将无法使用它们。鉴于我们必须将应用程序从几百个用户扩展到几千个用户，产品负责人非常重视性能技术债务，我们在估计的迭代中完成了技术卡。
注意：可以在故事卡的估计范围内通过重构来修复的技术债务不需要技术故事卡。更大的技术债务将。对于需要技术卡的技术债务，确定业务影响并要求产品所有者优先考虑技术卡。然后办卡。不要为工程实践创造技术债务。做所有的估计都知道工程实践将成为估计的一部分。不要创建卡片来通过自动化单元、功能和性能测试来改造应用程序。相反，仅将工作包含在您正在估算的卡片中，并将自动化测试添加到您通过正在工作的卡片触摸的代码中。这将使应用程序能够随着时间的推移而改进，而不会停止进展。停止添加所有名片只能在应用程序无法执行或无法扩展等最严重的情况下保存。
如果您继承了没有自动化单元、功能和性能测试的代码库，请告知业务合作伙伴这种可悲的情况。让他们知道您将如何评估工作。创造技术债务，因为它是通过工程实践发现的。最后，通知产品负责人，随着越来越多的代码库涉及自动化单元、功能和性能测试，团队的速度将会提高。
【讨论】：
我在敏捷环境中工作，但在采用敏捷技术之前，当前的代码库已经存在了好几年。这导致必须尝试以敏捷的方式工作，围绕未考虑自动回归测试编写的代码。
由于技术债务会影响我们交付新功能的速度，因此我们会记录由于使用遗留代码而增加了多少时间。这些数据使我们能够为专门用于偿还技术债务的时间提供理由。因此，当客户（无论是经理、CTO 或其他任何人）认为估算值过高时，您的数据可以巩固您的地位。
当然，有时您会发现您的估算会因为您不得不还清技术债务的遗留代码的意外怪癖而超出。我们发现，只要能解释和解释额外的时间，并为所花费的额外时间的好处提出一个案例，它就被普遍接受了。
当然，YMMV 取决于客户或其他因素，但拥有代表未来技术债务影响的统计数据非常有用。
【讨论】：
我认为询问客户希望使用该应用程序的时间是一个好主意。如果应用程序的生命周期有限（例如三年或更短），那么在重构上投入大量精力可能没有意义。如果预期（或希望）寿命更长，那么重构的回报就会变得更具吸引力。
您可能还想尝试为重构投资创建业务案例。展示您想要进行的改进类型的具体示例。对成本、风险和预期回报进行诚实的评估。尝试找到您可以独立于其他人实施的特定重构，并游说批准将该更改作为重构过程的测试运行。
请注意，当您谈到回报时，您可能需要提供具体数字。仅仅说“修复错误会容易得多”是不够的。相反，您应该准备好说“我们将看到错误修复的周转时间至少提高 30%”或“我们将减少 40% 的回归”。您还应该准备好与管理层和/或客户进行谈判，以便大家都同意您拥有对他们有意义的度量，并提供重构前后的度量。
【讨论】：
减少技术债务是我们每次提交代码时每个人都应该做的事情。
当您编辑代码时，您会进行一些整理，就像离开露营地之前的侦察员一样。
这样，经常更改的代码将处于更好的状态，这对业务有利。
永不改变的代码不会改进，但如果它有效，为什么还要改进呢？
不要为此安排任务，尽管长期计划很有帮助，讨论问题的论坛也是如此。
非常大的项目将受益于某种锁定方案，这样两个编码人员就不会在不同步的情况下同时重构同一段代码。
/罗杰
【讨论】：