如何在保持意大利面条代码的同时保存我的理智[关闭]

Question

只是想听听一些建议（和舒适......），这将帮助我控制一些复杂的意大利面条代码 - 这是由多个程序员（通常从不相遇）长时间开发的代码。解决方案的功能只是相互补充。

通常我倾向于看到两种程序员：

1. “害怕死亡的程序员” - 那些家伙不会碰任何他们不需要的东西。他们可能会使用快速而肮脏的修复程序完成维护任务，这将使下一个程序员开始寻找他们的家庭地址;-) 优点： 有用 缺点： 你希望你再也不会看到这段代码..
2. “教师” - 那些可能会重写整个代码，同时完全翻新其逻辑。 优点： 好吧，有人必须做肮脏的工作...... 缺点： 需要更长的时间，可能其中一个最重要的功能将从产品中神奇地消失

从程序员生活中这个黑暗的一面听到你的个人经历会很高兴。

我特别好奇听到任何理论/实践建议，这将有助于我深入了解意大利面条维护任务而不会感到如此痛苦。

Answer 1

虽然最好的建议是，正如本主题的其他每一张海报都指出的那样，编写测试时，我经常遇到这种情况不切实际的情况。如果代码那么糟糕（1000行方法，嵌入和未记录的幻数，代码重复等等），它也可能有另一个问题，即它是深度耦合的，组件几乎不可能被隔离。

（示例 - 在启动时加载并缓存数百个不同数据库对象的代码库。组件假设存在缓存的随机部分，缓存的某些部分假定缓存的其他部分 - 另外，您必须加载整个事物得到任何东西 - 代码依赖于静态和混杂的公共状态变量，在那里无法确定谁设置这些变量，甚至是什么意思）

我能提出的最佳建议：

• 首先尝试修复简单/明显的事情。硬编码路径，幻数引用，明显的代码重复。也许快速发布可以消除最严重的20％违规行为的风险很低，并使下一步更容易实现。
• 为refarctoring获得组织支持 - 通常没有意愿或愿意做不会增加直接功能的工作，并且有可能破坏现有代码。当然，重构的理由很多，但不是每个人都会购买它们。如果组织不支持，您可能需要放弃。
• 让其他开发人员接受相同的观点 - 如果他们有任何好处，他们可能会对代码库感到不满意。如果新代码构建为更好的标准并且人们受到激励，他们将开始修复旧代码，因为需要应用调整。
• 如果某个特定的子系统真的非常糟糕，并且已达到几乎不可能实现新开发的程度，那么您可以利用这个机会重建它。

Answer 2

虽然我自己从未这样做过，但这种方法很有意义。在现有公开接口周围编写大量测试，以确保在进入并重构实现的狄更斯时功能不会改变。这将确保任何重构都不会改变应用程序的运行方式。

Answer 3

我知道，在一家着名的保险公司，我曾经做过系统管理员，所用的主要定价系统是一台名为GenZ的25年历史的大型机。我想，自九十年代中期以来，一个新的系统正在开发中，目前正在测试中推出

大型机可能在20世纪80年代运作良好 - 但自公司发展以来，增加了更多数据，系统需要更多。应用补丁，发生了更多问题，多年来一直如此。

目前，该系统与所述保险公司使用的至少200个其他应用程序接口，因此替换它将是非常困难的工作，并且可能是它被推迟了很长时间的原因。

现在新的系统（称为Maxx）正在推出，数百个应用程序将不得不逐步淘汰。

编码不好不是因为开发人员害怕做不需要的事情，只是大多数情况下，他们没有考虑到最远的事情，想到最糟糕的情况，或者想到消费者，员工可能会这样做和未来的开发人员。

Answer 4

1. 首先，获得管理层的购买，因为提供业务价值（如将来添加功能变得更加容易）需要改进代码。我个人浪费了宝贵的时间来改善临终应用程序。
2. 彻底了解域名，某些类型的域名鼓励某些（反）模式..这将有助于理解为什么事情就是这样。
3. 围绕遗留代码编写测试有助于我探索业务逻辑中的各种细微差别，这些细微差别使得现在的代码变得混乱。我个人从不瞄准遗留代码测试的代码覆盖（虽然是一种普遍的传播方法），它只会让你发疯。

Answer 5

好吧，我必须重新考虑一个用coldfusion，javascripts，html编写的噩梦网站，并使用插件夫妇...我是这个应用程序的唯一开发人员。维护网站和数据库的最后一个人被转移了。我被这个丑陋的野兽困住了。我确实重新考虑了一些文件和功能，但问题和错误不断出现。

我的问题应该集中在修复错误或重构，我想完全花时间重构vs被拉到服务变更请求或错误。

一些文件是8k行，因为prev dev（不是真正的dev）保留了复制和粘贴代码块而不是分离功能。这是一个非常紧密耦合的代码，一个文件中的小变化将需要在4到5个其他地方进行更改。

我建议将网站分成可管理部分的小单元，并从头开始重建。到目前为止，他们并没有真正倾听，而是继续问为什么网站很慢。

我通过从主要网站（本地）拉出并测试代码，一次到达那里。

Answer 6

我发现很多时候你可以将意大利面条的碎块分成至少单独的源文件，有时是单独的类，而不必重写任何实际的逻辑。如果你可以偷一些时间来修复一两个错误，那么你将远远超过你开始的地方。

之后，当更多的错误进入时，您可能能够更好地模块化。慢慢地，你可以用这种方式把意大利面拉直。

Answer 7

好吧，也许这只适合我的情况，但在这里：

考虑到上面的所有建议，如果我要长时间处理遗留代码，我会清理脏代码，非常流畅，所以我不打破它，如果不，我不会烦

Answer 8

在开始之前，我尝试在测试中包装非常糟糕的遗留代码。老实说，我在测试中非常扼杀它！然后我有信心潜入重构我需要的地方。

你可能想读

Working Effectively with Legacy Code

Answer 9

文献。彻底记录。你做出的每一个改变 - 你发现的每一个警告，你追踪的每一个奇怪的逻辑流程，每次你认为“这可以做得更好” - 记录它。

这是在没有实质性重写的情况下减慢并最终消除系统熵的唯一方法。

Answer 10

我知道的唯一方法是：

1. 写测试
2. 重构
3. 运行测试
4. 修复坏了什么
5. 为新功能编写测试
6. 介绍新功能
7. 运行测试
8. 修复坏了什么

你可以这样生活。

注意：有时候单位测试意大利面条代码真的很难：生成HTML的3Klines方法，与业务逻辑纠缠在一起的DAO，强耦合类......在这种情况下是一个带有自动重构的好IDE（能够提取方法，到开始）和一些测试工具，如Selenium可能会非常方便。

Answer 11

充分利用两者。将项目组织成逻辑部分，最好使用反向工程UML类图，并查看互连的位置。任何松散连接的东西都是重构的理想选择。在任何停机时间，也要检查强连接，并查看哪些组可以完全拆分为具有最少更改的单独模块。弄清楚在重写整个事情之前，真正发生了什么。

Answer 12

我正处于遗留代码应用程序的错误修复中。我试图永远不要打击以前的开发人员（特别是因为我还在学习）。我改变的一切都做了大量的评论，以便我可以再次找到它，以便下一个人了解代码的演变过程。

始终要记住，您无法了解编写代码的所有情况。虽然这不一定能成为糟糕的编程或逻辑的借口，但它肯定会让你的血压下降。

我也把我遇到的每一个头脑都当作一个学习新东西和/或尝试新事物的新机会。

Answer 13

这是我在保持10年历史的perl系统的同时解决这个问题的方法。为了给出一点点背景知识，这是最糟糕的一些。当我开始在公司工作时，我最初很沮丧，因为代码是如此糟糕的思考和布局（这是我的第一个编程工作）。到那次演出结束时，我有一个非常好的系统。

首先，每个新功能都被添加为一个或多个新模块。在现有代码之上没有任何内容被黑客入侵。这让我可以为新东西编写单元测试，提供对它的信心，因此与旧东西集成只需要一两行。

其次，任何错误修复都以相同的方式实现。我花了一些时间来弄清楚旧的东西发生了什么（不是搜索bug），我把它写成一个新的方法（或模块），并将它包装在测试中，然后通常可以替换。

然而，这只有在你有时间和买入才能完成时才有效。如果不这样做，请跟踪您在任何给定错误上花费的时间。特别是在同一文件，进程或其他任何内容中存在多个错误的地方。在某个时间点，很容易指出给定的代码集合并说这是非常糟糕的，花费了N个时间，是时候重写了。

我通过这种方法取得了成功，获得了荣誉称号“法医程序员”，这也是一项非常出色的技能，因为新工作通常已经编写了一些代码：P

Answer 14

• 要缓慢而刻意。
• 尽可能写测试，但是当你不能时，不要感到沮丧。意大利面条代码很少是可测试的代码。
• 请记住，在您有充分的理由做出他们所做的事情之前编辑代码的每个人。假设他们中最好的，你很可能会得到回报。
• 在尝试更改代码之前了解代码。
• 在学习的过程中记笔记，并在工作时保持最新状态。如果可以，请在维基上保留并共享它们。
• 使用修订控制系统，使每个更改尽可能小，并尽可能集中，并尽可能频繁地检查。
• 不要咀嚼超过你可以咀嚼的东西。当你进行一次改变时，你无疑会找到其他应该清理的东西。将其添加到您的待办事项列表中，并专注于您的原始任务。
• 像露营地一样对待项目：让它保持比你发现的更好的状态。并记住“更好”是相对的;你无法一次解决所有问题。

Answer 15

超出它:)

如果这不是一个选择，那么......首先，尝试做出它的正面和反面。对于我所处理过的东西，这通常是最困难的部分。您可以手动创建UML，您可以使用一些商业源代码“逆向工程”工具，或者您可以只跟踪代码。

当您了解代码时，是时候重构了。好好计划。尝试写一堆体面的测试。然后通过迭代的重构方法，编写其他测试，并检查（工作！）修改回源代码控制。

根据你是多么自虐，这可能是非常有趣或你自己的个人地狱:)