您刚刚编写了一堆代码，以便在压力下交付一些重要的功能。你已经走捷径了，你已经将一些代码混入了一些过于臃肿的类，其名称如 SerialIndirectionShutoffManager..
你告诉你的老板你需要一周的时间来清理这些东西。
“清理什么？”
“我的密码——它是猪圈！”
“你的意思是还有一些错误修复？”
“不是，更像是……”
“你会让它跑得更快吗？”
“也许吧，但那不是……”
“那你应该在有机会的时候把它写好。现在我很高兴你在这里，是的，我得继续请你这个周末来..”
我读过 Matin Fowler 的书，但我不确定我是否同意他对此事的建议：
这两种方法都是出于与经理沟通的需要。
你跟老板说什么？
在原始估算中包含重构时间很重要。在你交付产品后去找你的老板，然后告诉他你实际上还没有完成，这是在说已经完成了。你实际上并没有达到交付的最后期限。这就像一个外科医生做手术，然后不确定他把所有东西都放回了应该的样子。
将开发的所有部分（例如重构、可用性研究、测试、QA、修订）包括在您的原始计划中是很重要的。归根结底，这与其说是管理问题，不如说是程序员问题。
然而，如果你继承了一个烂摊子，那么你将不得不向老板解释最后一组程序员急于将项目推出门外，并且它一直一瘸一拐地前进。您可以暂时解决问题（就像他们可能所做的那样），但是每个创可贴只会延迟问题并最终使问题的修复成本更高。
对你的老板诚实，并明白一个项目在完成之前是没有完成的。
用他能听懂的语言说话。
重构正在偿还设计债务。
问问你的老板，为什么他每个月都要支付公司信用卡账单，而不是在收到催款通知之前不支付。告诉他重构就像每月付款一样。
说谎。告诉他这是对新技术的研究。然后告诉他你认为成本并不能证明收益是合理的。他会认为你做得很好。
大声笑@人们降低改装/标记攻击性。
真的，如果是一个吝啬的老板，不懂好软件和便宜的软件，他不懂的东西最终会让他更快乐。如果是我，我会离开公司，去一个他们尊重他们的开发人员编写好的代码能力的地方。但话又说回来，这就是我处于高级职位的原因。
只需执行此操作并将其安排到您的正常流程中即可。估计重构时间到开始新的更改或完成更改（理想）。我总是在最初探索新代码（提取方法等）时进行重构。
告诉他与软件项目相关的 80% 的成本来自生命周期的维护阶段。现在为缓解未来问题而进行的任何重构，并提供一些示例，将在以后需要维护该代码时获得可观的成本收益。
这是假设您出于某种原因进行重构，而不是出于程序员的虚荣心。
重构你应该一直做......所以你不应该证明它是合理的。
清理大混乱/重新设计可能包括重构以使其得到控制，但它不是“重构”
重构应该是片刻的事情......或者如果你没有工具支持，几分钟。
在 Robert Glass 最近的一本书中（我必须查阅参考资料），他提到了一项关于维护良好的代码成本的研究。他们发现，维护良好的代码比维护不善的代码更容易被编辑。这听起来违反直觉，但当他们深入挖掘时发现了原因：
与维护不善的代码相比，维护良好的代码在同一时间范围内添加了更多功能。
你的老板喜欢功能吗？当然，他们都这样做。如果您提高代码的可维护性，您将能够在有限的预算下提供更多的功能。
我喜欢 Martin Fowler 在“重构”中给出的答案。告诉你的老板，你将以你知道的最快方式开发软件。碰巧在大多数情况下，开发软件的最快方法是随时重构。
要告诉老板的另一件事是，您正在降低成本以进行未来的改进。
现在我重构的钱少了……
或者以后有更多的钱来解决任何问题并让我进行重构。
有时，是时候找一份新工作了。有些人只是希望你“完成它”。如果您曾经遇到过其中一种情况，而我曾经去过那里，那就离开吧。
但是，是的，关于未来成本的所有其他内容都是好主意。我只是认为大多数老板都在骗自己，因为他们想要什么就什么时候想要什么，他们只是看不到未来会发生什么。
所以，祝你老板好运。Hpefully他或她是合理的。
不要....只是去一个与你更同步的地方找一份新工作。
我认为你应该在不告诉你的老板的情况下开始工作。这确实是我尽力而为的方式。我只是不告诉我的老板我在做什么，并在我有时间的时候慢慢替换坏/遗留代码。
它不止一次地救了我的屁股。
如果您的老板不了解重构或清理代码的必要性，那么您必须怀疑他是否有足够的工程知识来担任工程经理。
很少有老板会给你时间重构……只要你边做边做。
在我看来，重构最简单的情况是修复过于复杂的代码。测量相关源代码的 McCabe 圈复杂度（Source Monitor 是解决此类问题的绝佳工具）。具有高圈复杂度的源代码具有强相关性缺陷和不良修复。简而言之，这意味着复杂的代码更难修复，而且更可能有错误的修复。这对经理来说意味着产品的质量可能会更差，错误更难修复，项目的进度最终会更糟。然而，在重构复杂性的过程中，您正在提高代码的透明度，减少模糊/困难错误的可能性，并使其更易于维护（例如，维护程序员因此可以拥有更大的维护范围）。
此外，您可以证明（如果它不是维护周期中的死产品）降低复杂性会使应用程序在向项目中添加新需求时更容易扩展。
老板必须信任开发人员做出正确的技术决策（包括何时重构）。
建立信任或更换老板或更换开发人员。
另一个很好的比喻是维护一个整洁的建筑工地。这里唯一的问题是程序员不代表建筑工人，经理不代表工头。如果是这样的话，他的“第一次做对”的计数器仍然适用，因为一个称职和尽责的建筑工人有责任在他们工作的过程中保持工作空间的良好秩序。
真的代码本身就代表劳动者，开发过程就是工头。混乱是由围绕彼此的业务进行的各种行业产生的（即，不同的代码功能相互作用，每个功能都很好地完成了它的工作，但它们之间的接缝是杂乱无章的），并由工头坚定地清理密切关注混乱发生的位置，并采取行动将其清理干净（即要求重构的软件过程）。
我最近所做的就是向我的业务伙伴解释，重构过程有助于更快地开发新功能并降低新错误的可能性，因为代码具有更好的顺序和结构，甚至可以进行一些速度改进因为您可以比以前更容易地检查代码。
当业务人员明白这一点时，如果他们很聪明，他们会鼓励您进行持续的重构过程。
你可以用建筑比喻来解释这一点。如果您不进行重构，那么您将以糟糕的核心建筑而告终，因此您将遇到管道，窗户，门的问题。