你如何说服你的经理你的项目需要大量的重构？
我作为承包商加入了铁路项目。 该项目已经持续了一年多。 代码由大约10个不同的开发人员编写，其中大多数也是承包商。 他们有不同的代码风格。 其中一些来自Java。 该代码与metric_fu的分数很可怕。 许多function都很长（100 – 300行）。 某些函数具有大量的逻辑分支，循环和递归。 每个请求都会生成大量的SQL查询。 表现非常糟糕。 许多过时的代码从未使用但从未有机会被清理。 核心架构是完全错误的或过度设计的。 代码覆盖率仅为25％左右。 观点和部分是混乱的，阅读和理解很糟糕。
经理通过不断添加新function来尝试满足CEO，但是新function越来越难以正确实施而不会破坏其他function。 他知道代码很糟糕，但不想花太多精力修复它们，因为重构会花费太长时间。
作为承包商/开发商，有什么方法可以清除这种情况并方便经理或首席执行官分配一些时间进行重构？
相关问题
我如何说服持怀疑态度的管理层和同事允许重构糟糕的代码？
如何重构预算
处理不合逻辑的经理人
在我有限的经验中：
-
要说服经理人有必要留出时间进行重构是不可能的。 你可以让他意识到这一点，并且每次因为代码错误而遇到问题时都会强调这一点。 然后继续前进。 希望你的老板能解决这个问题。
-
参与正在运行的项目并认为“这是完全垃圾”是很常见的。 给它一些时间。 你可能会开始看到疯狂的模式。
我一直处于类似情况。 基本上只有两种选择：
- 你得到一些放松的时间，你可能有时间重构一些东西
- 由于代码不好，某些组件的进一步开发陷入了困境。 你不能继续添加任何东西，因为每一个小小的改变都会导致其他一切停止运作。 在这种紧急情况下，您将获得重构的“去”。
我刚刚回答了一些其他问题，我的恐怖故事：
我参与了一个项目，其中肮脏的技巧是开发的主要驱动原则。 需要说的是，经过一段时间这些技巧已经开始相互冲突。 在一个分析组件中，我们必须实现另一个非常脏的技巧 – 隐藏那些由于冲突技巧而未能正确计算的计算值。 之后，第二级技巧开始发生冲突，我们不得不制造技巧来处理这些问题。 从那时起，即使提到这个组件，也让我感到恐惧，我可能不得不再次努力。
这正是第二种情况，重构是唯一的出路。
一般而言，许多没有技术背景的管理者（实际上，那些来自不良程序员的管理者）既不关心也不了解质量代码和良好架构的价值。 在中断他们的计划之前，你无法让他们倾听，比如“不可实现”function的爆发，增加和重复出现的错误，无法满足的客户请求等等。 只有这样才能第一次理解代码问题。 通常，到那时为时已晚。
重构糟糕的代码是编码的一部分，因此除非您的经理正在密切关注您的代码或数小时，否则您无需获得任何人的批准。 我今天节省重构的时间是我不需要为了明天正常代码工作而花费大量工作的时间（所以它最终会成功）。
将方法分解为更小的方法并删除未使用的方法是您工作的一部分。 在您调用的代码中减少DB调用也是必要的，这样您的代码就不会太糟糕了。 再次，不是真正的重构，只是正常的编码。
说服你的经理取决于其他因素，包括（但不限于）他们的说服意愿，以及你说服的能力。
无论如何，RoR中的大规模重构是什么？ 即使“核心架构完全错误”，它通常也可以逐步理顺。 确保你把它分成块/使用树枝，这样你就不会在忙碌的时候破坏任何东西。
如果这是不可能的，那么你回到社交问题，如何说服你的经理。 这是一个简单的问题，可以弄清楚他/她的按钮是什么，并推动他们不被解雇或被捕。 羞辱，扣留食物，给予奖品，成为朋友，匿名绑架威胁，你介入并拯救一天……这很简单，真的：创造力是关键！
每个人都缺少一点：
重构是软件开发生命周期的一部分。
这不仅是一个RoR或任何特定项目，而是任何其他软件开发项目。
如果以某种方式你可以说服你的PM 为什么在添加任何新function之前重构现有的代码库是很重要的 ，那么你就完成了。 您应该明确告诉您的PM，任何进一步添加新function而不进行任何重构都将花费更多时间。 即使添加了该function，不知何故，由于代码非常庞大且无法维护，因此错误解析会话将花费更多时间。
我真的不明白为什么人们会忘记以后的优化原则。 稍后优化还包括后面的重构恕我直言。
还有一件事，在做出设计决策时，你应该非常清楚地告诉你的PM，无论好坏。
如果你的PM坚持添加新function和重构，你可以创建一个不同的分支（我假设你正在使用git）进行重构并开始在其他分支中添加新function。
一个棘手的问题，我最近在这样一家公司工作……他们总是在推动新事物，他们再次知道这很糟糕，但无论我怎么努力推动它 – 我甚至还有外部顾问来核实我的调查结果 – 他们认为这是浪费时间。
最终他们看到了光……它只花了多次服务器崩溃，而且在一个点上几乎整整8天都没有网站来说服他们。
即便如此，他们坚持认为它“必须”是托管服务。
关键是要尝试量化他们的网站在其崩溃之前将持续多长时间，并获得一些外部validation来支持你 – “他们”总是信任那些对你的应用一无所知的外人！ 此外，尝试 – 如果可以的话 – 提出一个涉及最坏情况下逐步替换的计划，并计划这样做需要多长时间。 还有一个计划，如果1或2个机构正在进行完全重写，可能需要很长时间 – 但也要现实，否则它会让你陷入困境！ 如果你走这条路（这就是我们所做的那样），只要你把它合并到新网站中，你仍然可以在现有网站上做一些工作。
我建议你把重点放在他们可以看到的东西上，也就是说，他们肯定会注意到应用程序在某些function上很慢，所以选择其中一个并说“我可以减少这里的等待时间” ，我可以花一些时间来改善这个具体的事情吗？“ （说得好，但你明白了：P）。
还要考虑10个开发人员在你没有重构代码库之前，这可能意味着它是一个monstrutru任务，可能会使情况变得更糟，在这种情况下，如果重构后出现问题，那将是你的错，如果程序不再正常工作。 只是一个，但值得考虑。
我会拿一小块应用程序进行重构和优化，直到它发光（我会在个人时间这样做，以免惹恼我的经理）。 然后，您将能够向您的经理/ CEO展示重构和SQL优化的良好结果。
如果需要重构，则代码将自行说明。 在开发过程中可以继续进行轻微的重构。 如果你不能说服经理，那么你可能应该重新思考是否有必要。
但是，如果绝对必要，那么构建开发活动的指标和收益应该说服经理。
我认为其中一个选择是向管理者强调如何重新分解代码库现在将在长期内节省时间（即金钱）。 如果项目期望长期运行，那么现在进行更改将明显节省您和其他开发人员的未来时间。
最好使用一个function的示例，您已经用它来估计如果您首先使用更干净的代码，将花费多长时间。 祝好运！
我现在处于相同的位置，但与经理达成协议，当新function应该在某个现有模块中实施以重新计算模块时（如果需要重新分解），我们现在正在努力代码创建于4 – 5年前，我发现重新考虑别人的代码并不是微不足道，也不是有趣的，但对未来的重用非常有帮助。