你如何证明重复工作给你的吝啬老板？

Question

您刚刚编写了一堆代码，以便在压力下提供一些重要功能。你已经削减了几个角，你已经将一些代码混合到了一些名为SerialIndirectionShutoffManager的过于繁琐的类中。

你告诉你的老板，你需要一周的时间来清理这些东西。

“清理什么？”

“我的代码 - 它是猪圈！”

“你的意思是还有一些bug修复？”

“不是真的，它更像......”

“你会让它跑得更快吗？”

“也许，但不是......”

“那么你应该在有机会的时候把它写得恰到好处。现在我很高兴你在这里，是的，我将不得不继续请你们这个周末来这里......” p>

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

• 鼓励定期进行代码审查，因此鼓励重构工作作为开发过程的自然部分。
• 只是不要告诉你，你是开发人员，也是你职责的一部分。

这两种方法都不需要与经理沟通。

你告诉老板什么？

Answer 1

在原始估算值中包含重构时间非常重要。在您交付产品然后告诉他您实际上没有完成之后，去找您的老板就是在撒谎。您实际上没有完成可交付的截止日期。这就像外科医生做手术，然后不确定他是否按照预期的方式恢复了所有内容。

在原始计划中包含开发的所有部分（例如重构，可用性研究，测试，质量保证，修订）非常重要。最终，这不是程序员问题的管理问题。

然而，如果你继承了一团糟，那么你将不得不向老板解释，最后一批程序员急于让项目走出大门并且一直在跛行。你可以暂时解决这个问题（正如他们可能做到的那样），但是每个创可贴只会延迟问题并最终使问题变得更加昂贵。

对老板说实话，明白项目一旦完成就不会完成。

Answer 2

用他能理解的语言说话。

重构是支付设计债务。

询问你的老板为什么每个月都要支付公司的信用卡账单，而不是在有收款通知之前支付。告诉他重构就像每月付款一样。

Answer 3

只需执行此操作并将其安排到正常流程中即可。估计重新开始新变更或完成变更（理想）的重构时间。 在我最初探索新代码（提取方法等）时，我总是重构。

Answer 4

烈。告诉他这是对新技术的研究。然后告诉他你决定费用并没有证明其好处。他认为你做得很好。

大声笑@人们改变/标记攻击性。

真的，如果这是一个吝啬的老板，谁不懂廉价软件的好软件，他不知道的最终会让他更快乐。如果是我，我会离开公司，前往他们尊重开发人员编写优秀代码的能力。但话说回来，这就是我处于高级职位的原因。

Answer 5

告诉他与软件项目相关的80％的成本都处于生命周期的维护阶段。现在为减轻未来问题所做的任何重构，并有一些例子，将在以后需要维护该代码时获得实质性的成本效益。

这假设你是因为某种原因而重构，而不是程序员虚荣。

Answer 6

重构你应该一直做......所以你不应该为它辩护。

清理大型混乱/重新设计可能包括重构以控制它，但它不是“重构”

重构应该是一个时刻......或者如果你没有工具支持，分钟。

Answer 7

在Robert Glass最近出版的一本书中（我将不得不查阅参考文献），他提到了一项关于维护良好的代码成本的研究。他们发现，维护良好的代码的编辑频率低于维护良好的代码。这听起来很反直，但当他们挖得更深时，发现了原因：

维护良好的代码在相同的时间范围内添加了更多功能，而不是维护良好的代码。

你的Boss喜欢功能吗？当然，他们都这样做。如果您提高代码的可维护性，则可以使用有限的预算提供更多功能。

Answer 8

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

另一件事告诉你的老板，你正在降低未来改进的成本。

Answer 9

我最近刚刚做的是向我的业务伙伴解释，重新制作流程有助于更快地开发新功能并降低新错误的可能性，因为代码具有更好的顺序和结构，甚至可以制作一些速度提高，因为您可以比以前更容易地检查代码。

当业务人员明白这一点时，如果他们聪明，他们会鼓励你做一个持续的重新制作过程。

你可以用建筑比喻来解释。如果你不做重构，你会以一个糟糕的核心建筑物结束，这样你就会遇到管道，窗户，门的问题。

Answer 10

另一个很好的类比是维护整洁的建筑工地。这里唯一的问题是程序员不代表建筑工人，经理不代表工头。如果是这样的话，他的“第一次做正确”的反击仍然适用，因为一个称职和尽职尽责的建筑工人有责任在工作时保持良好的秩序。

代码本身确实代表了劳动者，而开发过程就是工头。混乱是由各种各样的交易产生的（即通过不同的代码特征相互作用，每个特征都能很好地完成工作，但它们之间的接缝是混乱的）并由工头清理干净并且密切注意陷入困境的地方，并采取行动将其清理干净（即软件过程要求重构）。

Answer 11

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

建立信任或替换老板或更换开发。

Answer 12

在我看来，最简单的重构案例是修复过于复杂的代码。测量有问题的源代码的McCabe圈复杂度（Source Monitor是解决此类问题的极好工具）。具有高圈复杂度的源代码具有很强的相关缺陷和不良修复。简单来说，这意味着复杂的代码难以修复，更容易出现错误的修复。这对经理来说意味着产品的质量可能会更差，而且错误更难解决，项目的进度最终会更糟。但是，在重构复杂性时，您正在提高代码的透明度，减少隐藏/困难错误的可能性，并使其更易于维护（例如，维护程序员可以因此而拥有更大的维护范围）。

此外，您可以制作案例（如果它不是维护周期中的死产品），那么降低复杂性会使新应用程序添加到项目时更容易扩展应用程序。

Answer 13

很难找到能让你有时间重构的老板......只要你一起去做就行。

Answer 14

如果您的老板不理解重构或清理代码的必要性，那么您不得不怀疑他是否具备足够的工程知识才能成为工程经理。

Answer 15

我认为你应该在不告诉老板的情况下开始研究它。这真的是我做得最好的工作。我只是不告诉我的老板我在做什么，并在我有时间时慢慢替换坏/遗留代码。

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

Answer 16

有时，现在是时候找一份新工作了。有证据的人只是希望你“完成它”。如果你曾经遇到其中一种情况，而且我一直在那里，那就离开吧。

但是，关于未来成本的所有其他事情都是好主意。我只是认为大多数老板都骗自己，因为他们想要什么，他们想要什么，而他们只是无法看到将来会发生什么。

所以，祝你老板好运。他或她很合情合理。

Answer 17

现在给我的钱很少重构......

或更多的钱以后解决任何出错的问题并让我重构。

Answer 18

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