我想问你一些关于脏代码的问题。有些初学者在中等项目上编码。该代码是一个非常大的泥泞球。他们不是高级程序员。他们只知道如何稍微使用一下Java键盘。他们只是在主类中编写了12,000行代码，但是6000行属于NetBeans本身。

我的工作是分析代码并提出维护代码的好方法。我的想法是取消该项目，并使用OOP方法启动一个新项目。最近，我从该站点和其他站点收集了有关该问题的一些注释和想法。

现在，我有以下问题：

1. 我们应该修复代码并将其更改为OOP吗？我们现在正在调试它。
2. 该代码没有注释，没有文档，没有特定的编程风格，等等。更改它确实非常昂贵且耗时。我们能对此做什么？
3. 我如何教会他们遵循所有规则（注释，OOP，良好的代码质量等）？
4. 代码错误且容易出错。我们能做什么？测试？我们几乎写了两到三份A4纸进行校正，但似乎无止境。

我必须说我对他们是陌生的。我想我也违反了为项目添加新成员的规则。你认为我必须离开他们吗？

步骤0：备份到SCM

正如JBRWilkinson在评论中所暗示的那样，因为版本控制是抵御（不可逆）灾难的第一道防线。

还备份软件配置详细信息，创建可交付成果的过程等。

步骤1：先测试

然后开始编写测试：

• 对于什么有效，
• 对于失败。

无论您决定做什么，都可以得到保障。您现在可以：

• 开始从头和重写，
• 或修复它。

我的建议是从头开始构建通用体系结构，但要从混乱中提取验证检查点的部分，并在您认为合适时对其进行重构。

步骤2：验证和监控

设置一个持续集成系统（作为步骤0和步骤1的补充）和一个持续检验系统（为步骤4做准备）。

步骤3：站在巨人的肩膀上

（如往常一样...）

• 重构为模式
• 重构：改进现有代码的设计。
• 有效使用旧版代码（由Jason Baker推荐）
• 重构

步骤4：清洁

不用说，但您可能不想在代码本身上略读，而只是想在损坏的代码库上运行linters / static分析器和其他工具，以查找设计和实现中的错误。

然后，您可能还需要运行代码格式化程序，这将对整理工作有所帮助。

步骤5：审查

通过重构或清除漏洞很容易引入小错误。只需要选择一个错误并快速按下一个键，您可能会删除一些相当重要的东西而没有先意识到。有时效果只会在几个月后出现。当然，上述步骤可以帮助您避免这种情况（尤其是通过实施强大的测试工具），但是您永远不知道会发生什么，并且会遗漏什么。因此，请确保至少要有另外一对专用的眼球来审查您的重构（最好是更多的）。

步骤6：面向未来的开发过程

采取以上所有措施，并使其成为您常规开发过程的固有组成部分（如果还没有的话）。不要让这种情况再次发生，请与您的团队一起在您的流程中实施保障措施，并在您的政策中强制执行（如果可能的话）。将产生清洁代码作为优先事项。

但是真的，测试一下。很多。

就个人而言，在我手头有一份《有效使用旧版代码》的副本之前，我不会开始这个项目。认真地说，它正是为这类事情而写的。它充满了处理棘手代码的策略，并且比我在这里可以给您提供的细节要多得多。

我去过那里好几次了。我的规则是：如果该软件不是微不足道的（您拥有的资源可以使用超过1周的时间）并且可以正常工作，请保留该软件并继续进行增量重构。

如果该软件不能真正起作用（大量错误，不清楚的要求等），那么最好从头开始重写它。如果很小的话也一样。

重构的意义（如Fowler的书和Kerievsky的http://www.industriallogic.com/xp/refactoring/一样）在于它可以保持系统正常运行，也许重构将花费两倍的时间，但是风险为零。

从头开始重写可能会带来许多风险，从误解需求到错误的实施（毕竟，大多数团队都是一样的）。

我实际上看到一个复杂的过程从头开始重写了两次，但仍无法按预期工作。

我会完全重写它。有时不可能修复这样的代码。另一种选择是使其运行，而不添加任何新功能。为了教会团队编写良好的代码（经过精心设计，记录和测试），让他们修复您现在拥有的代码。让所有人修复错误/查看其他开发人员的代码，而不是其本人的代码。经过一些尝试，他们将了解到几乎不可能查看/修复此类代码。

在后期项目中增加人员很少有帮助。通常会违反截止日期。您应该尽一切可能成功完成项目，然后考虑离开。

我的建议是不要完全废弃整个代码。每个开发团队都面临着日常生活的问题。一次攻击一部分代码。修理，清洁，记录下来。然后移至另一部分。最主要的是总是随时准备一些可交付的代码。从头开始重写整个代码将花费直到现在为止所花费的时间，并且无法保证它会比现在更好。
但是，人们也应该避免以这种方式编写代码。花更多的时间进行代码审查。适应一些统一的编码风格。首先讨论设计，然后编写代码。这样简单的事情将会带来巨大的变化。

不错的博客讲述了Netscape为什么松动

如果可行，请对其进行重构。有一些工具可以帮助您做到这一点。如果不起作用，请使用神奇的代码改进命令，即deltree在Windows resp上。rm -rf在Linux上。

我们应该修复代码并将其更改为OOP吗？我们现在正在调试它。[...包含错误，没有文档...]

我去过那里，你对此表示同情。我什至写了一篇有关此的文章，这可能有助于您了解一些观点。简而言之：

如果代码中包含很多重复项，则应重写。如果没有可辨别的结构（没有清晰的接口，意大利面条），则重构将失败，您可能应该重写。

我如何教会他们遵守所有规则？

首先通过向他们展示自己可以从中受益的原因来说明他们为什么想要这样做。当他们同意并愿意学习时，就开始使用shuhari教他们。

我的建议是@duros和@Manoj R的答案的组合。

从头开始，请记住这次要创建好的代码/ OOP /注释/等，请从您的旧代码中引用/复制并粘贴。当您遇到旧代码的不良部分时，请重写/重构它们。

如果您的开发人员没有受过良好的培训，那么我认为最好将他们发送给课程。对于快速变化的IT行业中的定期培训而言，这很重要