我们刚刚编写了很多代码来在压力下提供一些重要功能。我们已经偷偷摸摸地将一些代码混入了一些过大的类中，这些类的名称类似于SerialIndirectionShutoffManager。

我们告诉老板，我们将需要一个星期来清理这些东西。

"清理什么？"

"我的代码是猪圈！"

"意思是还有更多错误修复？"

"不是真的，它更像是.."

"我们要使其运行更快吗？"

"也许吧，但是那不是。"

"那么，如果有机会，我们应该正确地编写它。现在我很高兴我们在这里，是的，我必须继续，要求我们在这个周末到来。"

我已经读过Matin Fowler的书，但是不确定我是否同意他的建议：

• 鼓励定期检查代码，因此鼓励将重构工作作为开发过程的自然组成部分。
• 只是不要说，我们是开发人员，是我们职责的一部分。

这两种方法都使我们不再需要与经理进行沟通。

你告诉老板什么？

解决方案

回答

说谎。告诉他这是对新技术的研究。然后告诉他，我们认为成本并不能证明收益的合理性。他会认为你做得很好。

大声笑@人们低调/令人反感。

的确，如果是一个一分钱的小老板，不懂廉价软件中的好软件，那么他所不知道的一切最终将使他更加快乐。如果是我，我将离开公司，去某个他们尊重开发人员编写良好代码的能力的地方。但是话又说回来，这就是为什么我担任高级职位。

回答

重构应该一直做下去。

清理大混乱/重新设计可能包括重构以使其受到控制，但是不是"重构"

重构应该只是片刻的事情...或者，如果我们没有工具支持，则只需几分钟。

回答

我喜欢Martin Fowler在"重构"中给出的答案。告诉老板我们将以最快的方式开发软件。碰巧，在大多数情况下，开发软件的最快方法是随我们进行重构。

告诉老板的另一件事是，我们正在减少进行未来改进的成本。

回答

告诉他，与软件项目相关的成本的80％来自生命周期的维护阶段。现在为减轻将来的问题而进行的任何重构，并有一些示例，将在以后需要维护该代码时获得可观的成本收益。

这是假设我们重构是出于某种原因，而不是出于程序员的虚荣心。

回答

只需将其安排在正常过程中即可。估计重构时间，以开始新的更改或者完成更改(理想)。
在最初探索新代码(提取方法等)时，我总是进行重构。

回答

用他能听懂的语言说。

重构付出了设计债务。

询问老板，为什么他每月都要支付公司信用卡账单，而不是等到收到催款通知后才付款。告诉他重构就像每月付款一样。

回答

现在我重建的钱更少了...

或者以后再花更多的钱来解决任何问题，并让我进行重构。

回答

在罗伯特·格拉斯(Robert Glass)的近期著作(我将不得不查找参考书)中，他提到了一项关于维护良好代码成本的研究。他们发现，维护良好的代码比维护不良的代码要经常编辑。这听起来很不直观，但是当他们深入挖掘时，发现了原因：

与维护得不好的代码相比，维护得好的代码在同一时间范围内具有更多的功能。

老板喜欢功能吗？当然可以。如果我们可以提高代码的可维护性，那么在有限的预算内我们将能够提供更多的功能。

回答

有时候，只是时候找一份新工作。有些人只是想让我们"完成"。如果我们曾经遇到过其中一种情况，而我去过那里，那就离开。

但是，是的，所有其他有关未来成本的东西都是好主意。我只是认为大多数老板都对自己撒谎，因为当他们想要时，他们想要他们想要的东西，而他们只是看不到将来会发生什么。

所以，祝你老板好运。希望他或者她是合理的。

回答

不要....只是在一个与我们更同步的地方去找份新工作。

回答

我认为我们应该在不告诉老板的情况下就开始工作。这确实是我尽力而为的方式。我只是不告诉老板我在做什么，有空的时候慢慢地替换坏/旧代码。

它不止一次地挽救了我的屁股。

回答

如果老板不了解重构或者清理代码的需要，那么我们必须怀疑他是否具备足够的工程知识以成为工程经理。

回答

将重构时间包括在原始估算中非常重要。在交付产品之后去找老板，然后告诉他我们实际上还没有完成，这是在说谎。我们实际上并没有确定交付期限。这就像一个外科医生在做手术，然后又不确定他是否把一切都放回了原来的样子。

将开发的所有部分(例如重构，可用性研究，测试，质量检查，修订)包括在原始计划中非常重要。归根结底，这不仅仅是程序员问题，而不仅仅是管理问题。

但是，如果我们继承了一个烂摊子，那么我们将不得不向老板解释说，最后一批程序员急忙将项目推到了门外，并且一直在发展。我们可以暂时解决问题(就像他们可能做的那样)，但是每次创可贴只会延迟问题，并最终使问题修复成本更高。

对老板诚实，并了解一个项目只有在完成后才能完成。

回答

很少有老板会给你时间重构...随你去做就可以了。

回答

在我看来，重构最简单的方法就是修复过于复杂的代码。测量所讨论源代码的McCabe循环复杂度("源监视器"是解决此类问题的出色工具)。具有高度循环复杂性的源代码具有很强的关联性缺陷和错误的修复。简单来说，这意味着复杂的代码更难修复，更可能具有错误的修复。对于管理人员而言，这意味着产品质量可能会更差，错误更难以修复，并且项目进度最终会更糟。但是，在重构复杂性时，我们正在提高代码的透明度，减少模糊/困难的错误的可能性，并使维护变得更容易(例如，维护程序员因此可以具有更大的维护范围)。

另外，我们可以证明(如果在维护周期中它不是废品)，当项目中添加了新的需求时，复杂性的降低使应用程序更易于扩展。

回答

老板必须信任开发人员做出正确的技术决策(包括何时进行重构)。

建立信任关系或者替换老板或者替换开发人员。