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

Question

您刚刚编写了一堆代码，以便在压力下提供一些重要功能。 你已经削减了一些角落，你已经将一些代码混合到一些名称如SerialIndirectionShutoffManager的过度膨胀的类中。

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

“干什么？”

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

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

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

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

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

“那么当你有机会的时候你应该写得很好。现在我很高兴你在这里，是的，我将不得不继续前进，并要求你在这个周末来这里。”

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

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

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

你告诉老板你怎么了？

Answer 1

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

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

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

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

Answer 2

用他能理解的语言说话。

重构是支付设计债务。

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

Answer 3

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

Answer 4

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

大声笑@人们降低modding /标记攻势。

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

Answer 5

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

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

Answer 6

重构你应该一直做....所以你不应该证明它是正确的。

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

当业务人员明白这一点时，如果他们聪明，他们会鼓励你做一个持续的再工厂流程。

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

Answer 10

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

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

Answer 11

现在为我重构的钱少了......

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

Answer 12

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

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

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

Answer 13

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

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

Answer 14

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

Answer 15

很难找到能让你有时间重构的老板......就像你去的那样去做。

Answer 16

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

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

Answer 17

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

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

Answer 18

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