当你学到新东西/更好的东西时，我应该回去修理工作吗？

Question

考虑到我们都在不断学习，我们都必须遇到一个问题，即我们学到的东西非常棒，可以显着改善我们的代码或部分代码。

问题是，当你学会了一些新的技术，策略或其他什么时，你应该或者你应该回到你知道有效的代码，但可以更好/可维护/更快/ 通常改进并实施这一新知识？

我理解“如果没有破坏，不要修复它”的概念，但是什么时候会失去你已经编写的代码的骄傲，以及它对重构有什么作用。

Answer 1

IMO，这取决于一些因素：

1. 当前项目与否 - 这是否会回到之前的项目进行更改并打开一堆蠕虫来执行此操作？在我工作的地方，有我们当前的项目，虽然我可以学习这个和那个，我不打算进入较旧的项目并在尝试应用我认为简单的东西时产生新的问题。另一个想法是采取SourceSafe中的内容并将其移至Subversion，这可能对于只有一个版本控制软件很有用，但可能不会普遍被视为时间的明智投资，因为这里的大多数开发人员都习惯于使用两者。

2. 代码年龄 - 这个代码是我最近处理过的，还是我花了很多时间来理解我回来的时间？虽然这与上述类似，但我目前的工作项目自2008年6月以来一直在进行，所以我在一年或更久以前工作的东西真的可能不值得回去改变。

   < / LI>

3. 变化的规模 - 这需要几周还是几个小时？这也是需要考虑的因素，因为很少有变化有时会导致数小时的工作，以及由于变化中的副作用而成为新的错误。

这些是指导我以及试图记住的一些事情，因为某些东西可能看起来更好，但它并不一定适用于所有地方。例如，尝试在钉子上使用钻头并不是一个好主意，但如果您刚刚学会了如何使用钻头并希望使用它无处不在，那么其他工具可能会出现问题锤子或扳手可能更有用，所以不要忘记有适合工作的工具也是值得的。

Answer 2

是的，如果时间允许的话。通常它没有。

Answer 3

如果我们谈论的是生产代码，我会说在以下情况下进行更改：

• 您可以节省时间而不会危及其他项目/发布时间表
• 这些改进将使应用程序更有效/更快
• 如果从典型用户的角度来看性能改进不大，请将这些更改作为具有新功能的版本的一部分进行推广（不要仅进行重构版本，除非它对用户而言基本上是透明的）< / LI>
• 您的代码在源代码管理下。 “如果它没有破裂，请不要修理它”只适用于你不能立即恢复到不间断状态的情况。源控制对于此类更改至关重要。
• 您将对大部分将要重做的组件进行单元测试。你不想因为重构尝试而为用户搞砸任何东西;避免这种情况的最佳方法是进行测试，以验证前后行为是否相同。

Answer 4

尽管时间/预算/质量项目三角形，您不应该考虑重构您的代码，除非：

• 代码是错误的/马马虎虎与其他应用程序一起工作。
• 将会有一项新功能更新，将使用您经验丰富的代码;）
• 这是一个非企业项目（大约10年前使用PHP和文本文件撰写的母亲网络博客;））或开源项目 - 您可以在重构时获得满足感和体验。
• 当你的同事在使用你的代码时很生气。

当你写更多内容时，你会成为更好的程序员。

Answer 5

没有严格的规则，但总的来说，我接近的方式是： 如果它是个人项目，一定要。如果它取决于其他人的美元，那么通常你会推迟修复它，直到客户想要提供你将要提供的可维护性/性能提升的好处，或者直到你需要触摸该代码以进行其他改动。无论如何，请尽量确保您已获得测试保险，以确保您不会破坏任何现有功能。

Answer 6

我从来没有觉得你在很久以前写的重写代码是值得的，除非它被打破，因为它经常以一种从头开始的基本方式被打破。把你新获得的绝地技能集中在新的挑战上。

话虽如此，如果您重构，请确保准备好这些测试用例，以帮助您了解将要介绍的回归。

Answer 7

“新/更好”不能替代“在现场经过充分测试”。如果我的代码中的某些内容已经可靠地工作了多年，我就不会碰它了。

将您的代码视为像马蹄蟹 - 自从他们第一次出现以来，大自然发明了“更好”的做事方式，但它们仍然存在并且变得强大。

Answer 8

一般来说，不，“如果没有破坏就不要修理它”。但是，如果你做了大量的黑客/变通办法让事情变得有效，而且你知道这会在以后引起问题，那么重构它通常是值得的。

每项决策都基于努力/风险与收益。如果您很好地了解变更的范围并且可以准确地估算定价成本，那么它可能会得到回报。但是，如果这是一个广泛的变化，这通常会导致版本2综合症，你开始重写一切，这就存在问题......

Answer 9

就个人而言，这是一个时间问题。如果我学到一些“新的和令人敬畏的”的东西，那么我会在我编写的任何新代码中实现它。

尝试在旧代码中实现此功能既需要更改代码，也需要修复由于我所做的更改而可能会在以后出现的任何问题。试图向我的老板解释在这些情况下出了什么问题非常困难，因为他不是程序员，也不理解程序员对我们编写的代码的骄傲。

但是，如果我回去查看旧代码，因为我必须更改某些内容（修复问题，实现新功能等），并且该代码让我思考（哎哟， WAS 我在思考？）然后是的，我改变了它，因为这是我正在努力的事情。

Answer 10

我的意见 - 当某人付钱修复时，应该回去修理“正常工作”。

当然，我是一位不悔改的资本主义顾问，我的大部分工作基本上都是客户出现了对XYZ应用程序的请求，我为他们构建了它。

那就是说，对于我的游戏项目（一个开源的.NET CBR阅读器），我总是很乐意立即实现新的东西 - 但同样，这就是它的用途。

Answer 11

我一直在思考这个问题并不是一个容易回答的问题。基本上，如果我想重写的代码可能永远不会再次使用，我就不这样做了。除非是我在工作之外写的东西。然后，如果它是一个很酷的程序，我很可能会重写它。但是，如果它与工作相关，我可能不会这样做，除非，它可以真正使代码更强大。

但除非你确定这是一个改进，否则我不会。

Answer 12

重构现有的[生产]代码，这些代码本来是功能性的并且通常满足其最终用户（并且在较小程度上对其维护者而言）通常是一个坏主意。这就是为什么

• 通常它没有经济意义。
• 它介绍了引入新bug的风险（确定性！），然后需要修复，这将对最终用户造成干扰
• 我们关于“做得更好”的想法通常仅仅与时尚或误解有关：保留新代码的新想法; - ）

在更哲学的层面上，有两点需要考虑：

• 工程与优雅/完美设计的区别
  工程设计使我们能够处理设计中的不完善之处！ 因此，虽然它是有用的并且通常有利于争取最优雅的设计方法，并且使用工具可以生成实用且可行的应用程序，即使它们的各个部分可能不是最佳的。

• 创造与进化的相对优势和缺点
  尽管与生物进化的类比因为软件进化更直接（即在进化过程中重新引入创造论的位）而破裂，但我们应该注意软件产品的不断发展可能会增加该系统的整体复杂性。

Answer 13

你有良好的单元测试覆盖率吗？如果你这样做并且你有信心可以在不破坏任何东西的情况下进行改变，那么为什么不呢？

如果我确定“改进”的方式实际上更好，我只会这样做。

Answer 14

好问题和我经常想到的问题。随着程序员的发展，维护遗留系统的能力将会降低，因此不要让您的系统变得太旧，否则将来维护它们将变得非常昂贵。

重写整个系统并不是一件轻松的事。多年来一直在修复小错误，并且很难再次从头开始捕获，因此需要大量的关注。

如果你可以将1000行代码减少到100，我建议这样做是值得的。如果这意味着要实现一个全新的框架来实现这一目标，那么除非其好处远远超过其缺点，否则我会另辟蹊径。

Answer 15

我想这取决于它是个人项目或工作的代码。如果它的工作，显然最终取决于你的老板。如果你能说服他们完成这个需要并且他们愿意给你时间远离其他项目去做，那就去做吧。

Answer 16

解决部分问题：

在我工作的地方，编辑未破坏的东西是错误的。在生产环境中，人们每天都在整天使用您的代码，您将因“调整”尚未报告为已损坏的代码而受到谴责。关于（优选地）你输入错字或意外改变某些功能的可能性很小，其他人在进行故障排除时会受到影响。换句话说，发展将导致支持问题。此外，支付某人对未破坏的东西进行更改是我的雇主倾向于避免的做法。