就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。
8年前关闭。
您刚刚编写了一堆代码来在压力下交付一些重要的功能。你已经偷了几个角落，你已经将一些代码混入一些过度膨胀的类中，名称如 SerialIndirectionShutoffManager..
你告诉你的老板你需要一周的时间来清理这些东西。
“清理什么？”
“我的密码——它是一个 pig 圈!”
“你的意思是还有一些错误修复？”
“不是真的，它更像是……”
“你想让它跑得更快？”
“也许吧，但那不是……”
“那你应该在有机会的时候把它写好。现在我很高兴你在这里，是的，我不得不继续请你这个周末来......”
我读过 Matin Fowler 的书，但我不确定我是否同意他在这件事上的建议:
这两种方法都是出于与您的经理沟通的需要。
你对你的老板说什么？
最佳答案
在您的原始估计中包含重构时间很重要。在你交付产品后去找你的老板，然后告诉他你实际上还没有完成，这是在说已经完成了。你实际上并没有完成可交付的最后期限。这就像一个外科医生在做手术，然后没有确保他把所有东西都放回原位。
将开发的所有部分(例如重构、可用性研究、测试、QA、修订)都包括在您的原始计划中是很重要的。归根结底，这与其说是管理问题，不如说是程序员问题。
然而，如果你继承了一个烂摊子，那么你将不得不向老板解释，最后一批急于将项目推出的程序员偷工减料，而且它一直在跛行。您可以暂时解决问题(就像他们可能做的那样)，但每个创可贴只会延迟问题的出现，最终使问题的修复成本更高。
对你的老板诚实，明白一个项目只有完成了才算完成。
关于refactoring - 您如何向吝啬的老板证明重构工作的合理性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/77193/