20.重构项目中的重复代码_如果该代码有效，请不要修复...或者可以吗？ 何时重构代码以及何时不使用它。

20.重构项目中的重复代码

Imagine software that you work on. It was written by programmers before you joined the team and the software works properly. There are some bugs that need to be fixed but it does what it’s supposed to do. Nothing else. This is what others see from outside of the code–software that solves customers’ problems and works as expected.

想象一下您正在使用的软件。 在您加入团队之前，它是由程序员编写的，软件可以正常运行。 有一些错误需要修复，但是它可以完成应有的工作。 没有其他的。 这是其他人从代码软件外部看到的，该软件可以解决客户的问题并按预期工作。

But what about the code? What about the programmers? What do they think about their software?

但是代码呢？ 程序员呢？ 他们如何看待他们的软件？

As one of the programmers that built this software, you see totally different things from inside the code.

作为构建此软件的程序员之一，您从代码内部看到了完全不同的事物。

First things first, you think the code base is so big. You know certainly that this software could have been written with much less code while still providing the same functionality. The code base seems so complex to you. You know that the code could have been written in a better, simpler, and more well-structured way.

首先，您认为代码库很大。 您肯定知道该软件可以用更少的代码编写，同时仍提供相同的功能。 代码库对您来说似乎太复杂了。 您知道该代码可以用更好，更简单，更结构化的方式编写。

Adding new features or implementing something new is hard and painful because you have to consider the other parts that are connected to each other. The modules are not loosely coupled, so making changes takes too much time. And what about debugging? Finding bugs and fixing them takes too much time as well.

添加新功能或实现新功能非常困难，因为必须考虑彼此连接的其他部分。 这些模块不是松散耦合的，因此进行更改需要太多时间。 那调试呢？ 查找错误并修复它们也会花费太多时间。

Besides the bad design and ugly code, the software works properly and the customers are happy. Now you are at the crossroads. There are two possible ways for you: one way tells you that you should follow the old engineering adage, “If it works, don’t fix it.” The other one that tells you that you should do some refactoring to make your job easier while working on your code base so that you have more readable and understandable code.

除了不良的设计和丑陋的代码外，该软件还可以正常运行，并且客户满意。 现在您正处于十字路口。 有两种可能的方法供您选择：一种方法告诉您应该遵循古老的工程格言：“如果可行，请不要修复它。” 另一个告诉您应该进行一些重构，以便在使用代码库时使工作更轻松，从而使代码更具可读性和可理解性。

Which way would you prefer? Would you follow the old engineering adage “If it works, don’t fix it?”

您会选择哪种方式？ 您是否会遵循古老的工程格言“如果可行，就不要解决？”

两种不同的程序员思维方式 (Two different programmer mindsets)

The answer to that question can be simple. But before explaining the appropriate answer, I want to introduce you to two different programmer’s mindsets when it comes to fixing bad code that works properly.

这个问题的答案很简单。 但是，在解释适当的答案之前，我想向您介绍两种不同的程序员在修复正常工作的错误代码时的心态。

The first mindset believes in the old engineering adage: “If it works, don’t fix it.” To them, their code style doesn’t matter. They are result-driven programmers. It can be complex, badly structured code, completely opposite of important programming principles, but they don’t care about how well the code is written. They just care about what it does.

第一种心态是古老的工程谚语：“ 如果可行，请不要修复。 对于他们来说，他们的代码风格无关紧要。 他们是结果驱动的程序员。 它可能是复杂的，结构错误的代码，与重要的编程原理完全相反，但是他们并不关心代码的编写程度。 他们只是在乎它的作用。

So to these programmers, fixing badly written code is a waste of time. It just works. Why should they touch it?! And besides, there is a big risk of introducing new bugs while fixing the bad code. So what will they do? They will not touch the code and continue following the old engineering adage.

因此，对于这些程序员而言，修复写得不好的代码是浪费时间。 它就是有效的。 他们为什么要触摸它？ 此外，在修复错误代码的同时，还存在引入新错误的巨大风险。 那他们会怎么做？ 他们不会接触代码，而是继续遵循古老的工程格言。

On the other hand, the other programmers who see the code as artwork will be uncomfortable with that kind of situation. They will feel disgusted while reading badly written code. They will try to fix each piece of code in the project because they care about code style a lot, and every piece of code in their project should be treated as art.

另一方面，将代码视为艺术品的其他程序员将对这种情况感到不舒服。 在阅读糟糕的代码时，他们会感到恶心。 他们将尝试修复项目中的每段代码，因为他们非常关心代码样式，并且项目中的每段代码都应被视为艺术品。

They are too obsessive about their code style. Even if other programmers write well-structured code, they will try to change that code to make it suitable to their own style. So basically they don’t follow the old “if it works, don’t fix it” adage. They will fix everything according to their own mindset. In the end, it doesn’t matter to them if it works or not.

他们对代码风格过于痴迷。 即使其他程序员编写结构良好的代码，他们也会尝试更改该代码以使其适合自己的样式。 因此，基本上他们不会遵循旧的“如果可行，就不要修复”的格言。 他们将根据自己的想法进行修复。 最后，对他们而言是否起作用无关紧要。

什么是最适合您的解决方案？ (What would be the best solution that works for you?)

Find the parts of code that you work on actively and fix these parts to make them more understandable and readable. Don’t touch other parts if they work as expected and they are bug-free.

查找您正在积极工作的代码部分，并修复这些部分以使其更易于理解和可读。 如果它们按预期工作并且没有错误，请不要触摸其他部分。

Why is this core so important? The core parts of your software are the parts you will work on the most. You will read these parts more often and will make changes in them more often than the rest. If there is a need for adding additional functionalities or implementing new features, they will be connected directly to the core.

为什么这个核心如此重要？ 软件的核心部分是您将最常使用的部分。 您将比其他部分更频繁地阅读这些部分，并在其中进行更多的更改。 如果需要添加其他功能或实现新功能，它们将直接连接到核心。

Most of the bugs will be introduced from this core, which means you will spend most of your time debugging these parts. Remember the 80/20 rule (Pareto Principle), “20 percent of the code has 80 percent of the errors. Find them, fix them!”

大多数错误将从此内核中引入，这意味着您将花费大部分时间调试这些部分。 请记住80/20规则(帕累托原理) ， “ 20％的代码有80％的错误。 找到它们，修复它们！”

What about the other parts?

那其他部分呢？

Those parts are the ones that you will rarely work on. They are bug-free. They were written maybe even months or years ago and they work as expected. They might be written in an ugly way, even though they could have been written in a simpler, more readable and understandable way. This doesn’t mean that you have to fix them too. God knows when you will have to read them or change them again. So these parts can stay as they are. Forget about them. No need to fix them. You can spend your time working on more important stuff.

这些部分是您将很少涉及的部分。 它们没有错误。 它们甚至在几个月或几年前就已经写好了，并且按预期工作。 即使它们可能以更简单，更易读和易懂的方式编写，也可能以丑陋的方式编写。 这并不意味着您也必须修复它们。 上帝知道您什么时候需要阅读或再次更改它们。 因此，这些部分可以保持原样。 算了吧 无需修复它们。 您可以花时间在更重要的事情上。

为什么即使核心部件按预期工作也是如此重要？ (Why is fixing core parts so important even if they work as expected?)

If you want to serve your customers for many years, you should have a maintainable product. A maintainable product means that making changes is not a struggle. Debugging and fixing bugs shouldn’t take too much time and adding new features should also be easy. So as a result, your programmers are happy and your customers are happy, too.

如果您想为客户服务多年，那么您应该拥有一个可维护的产品。 可维护的产品意味着进行更改并非易事。 调试和修复错误应该不会花费太多时间，并且添加新功能也应该很容易。 因此，您的程序员很高兴，您的客户也很高兴。

As Martin Fowler said in his Refactoring book:

正如马丁·福勒(Martin Fowler)在他的重构书中所说：

“When you think about programmers, most of us will think that they spend most of their time writing code. Actually, this is quite a small fraction. Programmers spend most of their time reading the code and debugging it. Every programmer can tell a story of a bug that took a whole day (or more) to find. Fixing the bug is usually pretty quick, but finding it is a nightmare.”

“当您想到程序员时，我们大多数人会认为他们将大部分时间都花在编写代码上。 实际上，这只是很小的一部分。 程序员花费大量时间阅读和调试代码。 每个程序员都可以讲述一个花了一整天(或更长时间)才能发现的错误的故事。 通常，该错误的修复速度非常快，但是发现它却是一场噩梦。”

The more well-written code you have, the easier it is to understand the code. The more understandable your code is, the easier your job is.

您编写的代码越多，理解代码就越容易。 您的代码越容易理解，您的工作就越容易。

That is the reason why not following the old engineering adage (if it works, don’t fix it) for the core parts of your software is an important decision you can make.

这就是为什么对于软件的核心部分不遵循旧的工程格言(如果可行，请不要修复)的原因，您可以做出此重要决定。

翻译自: https://www.freecodecamp.org/news/advice-to-programmers-if-it-works-dont-fix-it-or/

20.重构项目中的重复代码

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！