你如何说服你的经理你的项目需要大量的重构？

Question

我作为承包商加入了一个铁路项目。该项目已经进行了一年多。代码由大约10个不同的开发人员编写，其中大多数也是承包商。他们有不同的代码风格。其中一些来自Java。该代码与metric_fu有可怕的分数。许多功能非常长（100 - 300行）。一些函数具有疯狂的逻辑分支，循环和递归量。每个请求都会生成大量的SQL查询。性能非常糟糕。很多从未使用但从未得到清理机会的过时代码。核心架构显然是错误的或过度设计的。代码覆盖率仅为25％左右。观点和偏见是混乱和可怕的阅读和理解。

这位经理正试图通过不断添加新功能来满足CEO的需求，但是新功能越来越难以正确实施而不会破坏其他功能。他知道代码很糟糕，但不想花太多精力修复它们，因为重构需要很长时间。

作为承包商/开发人员，清除这种情况以及方便经理或首席执行官分配一些重构时间的好方法是什么？

相关问题

How can I convince skeptical management and colleagues to allow refactoring of awful code?

How to refactor on a budget

Dealing with illogical managers

Answer 1

在我有限的experiance：

1. 这是不可能说服经理认为有必要留出时间来重构。您可以让他意识到这一点，并在每次因代码错误而遇到问题时强化这一点。然后继续前进。希望你的老板能弄明白。

2. 进入正在运行的项目并认为“这是完全垃圾”是相当普遍的。给它一些时间。你可能会开始看到疯狂的模式。

Answer 2

我已经在类似的情况。基本上有只有两个选择：

• 你得到一些放松的时间，你可能会被授予时间来重构东西
• 由于某些组件的恶意代码的进一步发展涉及到一个摊位。你不能继续添加任何东西，因为每一个小小的变化都会导致其他一切停止运作。在这种紧急情况下，你将会得到一个“去”重构。

我刚才已经回答了一些其他的问题，我的恐怖故事：

https://stackoverflow.com/questions/1333077/dirty-coding-tricks-to-deliver-project-on-time/1333095#1333095

我有一个项目，肮脏的把戏是发展的主要驱动原理工作。 Needlees说，一段时间后这些技巧已经开始相互冲突。在一个分析组件中，我们必须实现另一个非常脏的技巧 - 隐藏由于相互冲突的技巧由于计算不正确而计算出的值。之后，二级技巧开始发生冲突，我们不得不制造技巧来处理这些技巧。从那以后，即使提到这个组件，也让我感到恐惧，我可能不得不重新开始工作。

这正是重构是唯一出路的第二种情况。一般来说，许多没有技术背景的管理人员（实际上，来自坏程序员的人员）既不关心也不理解质量代码和良好体系结构的价值。只有当某些事情打断他们的计划时，他们才能让他们倾听，比如“不可实施”功能的打击，错误的增加和再次发生，客户的请求不能满足等等。只有这样，对代码问题的理解才会第一次出现。通常，到那时为时已晚。

Answer 3

我会带应用的一个小块和重构和优化它，直到它的光芒（和我做在我的私人时间，为了不骚扰我的经理）。然后，您将能够向您的经理/首席执行官展示重构和SQL优化的良好结果。

Answer 4

如果有需要重构，那么代码将为自己说话。在开发过程中可以继续进行较小的重构。如果你不能说服经理，那么你可能应该重新思考它是否有必要。

但是，如果这是绝对必要的，那么构建开发活动的指标和好处应该说服经理。

Answer 5

我认为其中一个选择是向经理强调如何对代码库进行重新分解以节省长期的时间（即金钱）。如果项目期望长期运行，那么现在进行更改将明显地为您和其他开发人员节省时间。

最好用你的估计多长时间，如果你有更清晰的代码从摆在首位的工作，将采取的工作特征的一个例子。祝你好运！

Answer 6

一个棘手的，我最近在这样的公司工作......他们总是推动新的东西，他们又知道这是不好的，但我无论怎样努力推动它 - 我甚至到了外部顾问验证我的发现 - 他们认为这是浪费时间。

最终，他们看到了曙光......只用了多个服务器崩溃，并在一个点上，几乎整整8天无网站的说服他们。

即使在他们坚持认为它一定是托管服务。

关键是要尽量量化他们的网站会持续多久，但仰卧起坐之前，并获得一些外部验证支持你 - 谁知道也不关心你的应用“他们”始终信任外人！此外，如果可以的话，尝试制定一个计划，以便在最坏的情况下逐步进行更换，并制定计划要花费多长时间才能完成。另外还有一个计划，如果有一两个人正在进行完整的重写，可能需要多长时间 - 但也要现实一些，否则会让你陷入困境！如果你走这条路线（这就是我们所做的），只要你把它融入到新的网站中，你仍然可以在现有网站上做一些工作。

Answer 7

我会建议你把重点放在事情，他们可以看到自己，那就是，他们肯定会注意到该应用程序是在一些功能缓慢，所以拿起其中一个，这样说：“我可以减少在这里等待的时间，我可以花一些时间来改善这个具体的事情吗？“ （更好地说，但你得到了点：P）。

另外考虑到10个开发者在你没有重构代码库之前，这可能意味着它是一个monstruos任务，可能会使情况变得更糟，在这种情况下，如果重构后出现问题，它将会是你的如果程序无法正常工作，则为错误。 只是一个虽然，但值得考虑。

Answer 8

我在同一位置的权利，但与该经理认为，当新的功能，应该在现有的一些模块来实现重新因子模块太（如果它需要重新分解）的协议，我们现在正在用4-5年前创建的代码挣扎，而且我发现重新分解别人的代码不是微不足道的，也没有趣，但对未来的重用非常有帮助。

Answer 9

每个人都在这里失去了一个观点：

重构是软件开发生命周期的一部分。

这不仅是一个回报率或任何具体项目，而是任何其他软件开发项目。

如果不知为何，你能说服你的PM why it is important to refactor增加任何新功能之前，现有的代码库，你就大功告成了。你应该清楚地告诉你的PM，没有任何重构的任何进一步添加新功能将花费比所需更多的时间。即使添加了该功能，错误解决会话也会花费更多的时间，因为代码非常庞大且不可维护。

我真的不明白为什么人们忘记了以后优化的原则。以后优化还包括稍后重构恕我直言。

一两件事，以设计决策的时候，你应该告诉后果，或好或坏，你的PM非常非常清楚。

您可以创建一个不同的分支（我假设你正在使用GIT）进行重构，并开始在其他一些分支添加新的功能。如果PM坚持与重构以及添加新的功能。

Answer 10

糟糕的重构代码是编码的一部分，所以你不需要得到任何人的批准除非你的经理正在密切关注你的代码和/或小时。今天我节省重构的时间是我不必为了明天正常代码工作而疯狂操作的技巧（所以最终得以实现）。

猛击了方法成更小的方法和删除不使用的是你工作的一部分方法。在你调用的代码中减少数据库调用也是必要的，这样你的代码就不会被吸引。再次，不是真正的重构，只是正常的编码。

说服你的经理取决于其他因素，包括（但不限于）他们愿意被说服的能力和说服力。

无论如何，RoR中的大规模重构是什么？即使“核心架构显然是错误的”，它通常可以一次性理清一点。确保你把它分成块/使用分支，这样在你忙于修复时就不会破坏任何东西。

如果这是不可能的，那么你回来的如何说服你的经理社会问题。这是一个简单的问题，可以确定他/她的按钮是什么，并且推动他们而不会被解雇或被捕。羞辱，拒绝食物，给予奖品，成为朋友，匿名绑架威胁，在你步入并挽救一天的过程中......这很简单，真的：创造力是关键！