Refactoring 评估重构工作

有没有办法估计重构工作？例如，我们知道跨类/包复制的代码行。现在，我们如何估计所需的工作量呢？

在较高的层次上，敏捷团队（这是我通常的环境）会像估计任何故事一样估计重构故事：作为一个团队，回顾故事的事实（在本例中包括重复的代码报告）并根据他们通常使用的单位（故事点或实际时间），直观地估计完成这项工作需要多长时间。如果故事可以分块完成（实现和交付），他们会将每个故事分成一个故事，并对其进行评估。（在这种情况下，每个不同的重复代码块或不同重复代码块的类可能有一个故事。）

这显然是不准确的，但对于小故事来说通常并不坏，而且它充分利用了团队对代码的知识。如果团队还不太了解代码，他们的估计就会不那么准确

要估计整个代码库的重构工作

• 基于整个代码库的代码质量报告，或者基于对代码库样本部分的手动审查加上外推来进行估计
• 为每个已知的问题写故事，估计它们，然后添加估计值

---

技术债务本身使估计值不那么可靠（也就是说，估计值太低），因为当你知道技术债务时，通常会有更多你没有确定的技术债务。与任何项目一样，如果评估是有价值的，请定期重新评估评估，以考虑您从迄今为止所做的工作中学到的知识。

是否有可能对给定代码库的整个重构工作做出评估？（重复代码、大型类、复杂方法等）团队不仅对代码库了解最少。