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