调试代码遗留_抓住一切机会来改进遗留代码

调试代码遗留

Living with a large legacy codebase is not pleasant. Changes are long, bugs accumulate, understanding is lost. However, nothing forces us to suffer these inconveniences forever. We can act, at any time, and right now. There is no need to start a big project for that, nor to plan a plan to go to the Moon. We can do refactoring in small steps and do it regularly. Take advantage of every opportunity (an evolution, a task, a correction) to improve the code around the changes. This simple concept allows us to improve the quality of the code over time.

使用大型遗留代码库并不愉快。 变化漫长，错误累积，理解力丧失。 但是，没有什么能迫使我们永远遭受这些不便。 我们可以随时随地采取行动。 为此，您无需启动大型项目，也无需计划前往月球的计划。 我们可以一步一步地进行重构，并定期进行重构。 抓住每一个机会(一个发展，一个任务，一个更正)来改进围绕变更的代码。 这个简单的概念使我们可以随着时间的推移提高代码的质量。

This summer, I had a bug to fix on a part of the application I hadn’t worked on yet. After a short walk through the code, I encountered the RoadMapBlock. The famous RoadMapBlock. It certainly doesn’t speak to you, but in our teams, this name has a big reputation. I heard that name in my early days. Its evocation aroused nervous laughter and despair. It’s even known to the non-technical people. But what is it then?

今年夏天，我有一个错误要修复尚未使用的应用程序的一部分。 经过短暂的代码浏览，我遇到了RoadMapBlock 。 著名的RoadMapBlock 。 它肯定不会和您说话，但是在我们的团队中，这个名称享有很高的声誉。 我早年听说过这个名字。 它的唤起引起了紧张的笑声和绝望。 甚至是非技术人员都知道的。 但是那是什么呢？

The RoadMapBlock is both a central component for one of the most important screens of the application and one of the big pain areas of the project. This element was created years ago and has since been modified by dozens of developers. To give you an idea, the class has about a hundred functions. The method that contained the bug was about a thousand lines and had a great complexity (a hundred ifs, several levels of nesting, loops, …).

RoadMapBlock既是应用程序最重要的屏幕之一的核心组件，也是项目的主要难题之一。 此元素创建于几年前，此后已被数十名开发人员修改。 为了给您一个想法，该类大约有一百个函数。 包含该错误的方法大约有1000行，并且具有很高的复杂性(一百个ifs ， 多层嵌套，循环等)。

A nightmare at first glance, but also a huge opportunity for improvement.

乍看之下是一场噩梦，但也有巨大的改进机会。

逐步重构遗留代码 (Refactoring legacy code progressively)

I started my work session by locating the error in the code. I felt that something was happening in a part of this function, but the area was hard to understand. So I started doing some quick refactoring to gain understanding. I did several refactoring operations to improve the code, to make it my own, and to see more clearly. It’s a quick way to understand legacy code that I like to use (I wrote more about it in my previous article). It was a great help. Soon after, the cause of the bug was obvious to me and I was able to fix it easily. The correction was a single line. But was it over? No!

我通过查找代码中的错误开始了我的工作会议。 我感觉此功能的一部分正在发生某些事情，但是该领域很难理解。 因此，我开始进行一些快速重构以获取了解。 我做了一些重构操作来改进代码，使其成为我自己的代码，并使其更清晰地看到。 这是一种理解我喜欢使用的遗留代码的快速方法(我在上一篇文章中对此进行了详细介绍 )。 这是一个很大的帮助。 不久之后，该错误的原因对我来说很明显，我能够轻松地对其进行修复。 更正是一行。 但是结束了吗？ 没有！

I was there, in the middle of all this legacy code. I had taken time to understand some of it, to analyze it, to load it all into my head. I had even made some changes here. Why not improve the code while I was still deeply involved in this context? Understanding legacy code is often difficult and time-consuming. It’s not something that motivates most developers either. We must seize the opportunity to improve it. We’re not likely to wake up one morning and say “I’m going to do that part just for fun”. If we don’t do it right now, we’ll probably never do it. This code that hurts us so much will remain a thorn in our side.

我在所有这些旧代码的中间。 我花了一些时间来理解其中的一些内容，进行分析，然后将其全部载入我的脑海。 我什至在这里做了一些更改。 当我仍然深入参与这种环境时，为什么不改进代码呢？ 了解遗留代码通常是困难且耗时的。 这也不是大多数开发人员的动力。 我们必须抓住机会加以改进。 我们不太可能在一个早晨醒来，并说“我只是为了好玩而去做这部分”。 如果我们现在不这样做，我们可能永远也不会这样做。 如此严重伤害我们的代码将仍然对我们不利。

So I started refactoring again cleanly. My gain in comprehension allowed me to do it better. I renamed some variables and methods. I extracted methods to start splitting and structuring. I decreased the nesting levels of if, switch, and for. Simple actions which will help a lot in the future. We read a lot more code than we write. Doing refactoring now will help us to better understand and change this code every other time.

因此，我开始重新整洁地重构。 我的理解能力使我能够做得更好。 我重命名了一些变量和方法。 我提取了一些方法来开始拆分和结构化。 我降低了if ， switch和for的嵌套级别。 简单的动作将在将来大有帮助。 我们阅读的代码比编写的要多得多。 现在进行重构将有助于我们每隔一段时间更好地理解和更改此代码。

It is also a foundation for wider refactoring. The succession of small improvements facilitates a more consequent refactoring. One day, it will be easy to rewrite everything. The refactoring of a complex function of a thousand lines requires a huge effort. But this same function, divided into several small simple functions, better named, better structured, is much easier to modify. Maybe it will not even be necessary anymore, the structure of the code may be good enough to be understood and to evolve.

它也是更广泛重构的基础。 一系列的小改进可以促进后续的重构。 有一天，很容易重写所有内容。 重构一千行的复杂功能需要付出巨大的努力。 但是，将这个相同的功能分为几个小的简单功能，更好的命名，更好的结构化，则很容易修改。 也许甚至没有必要了，代码的结构可能足以理解和发展。

The improvement of the code surrounding our modifications can be done very quickly. I guess I didn’t take more than an hour. One hour on the life of a product is nothing. And yet, it’s a big gain. We act now, we start doing. It’s easy to complain about legacy code, it’s also easy to make improvements in small steps. However, complaining won’t get things done.

围绕我们的修改的代码改进可以很快完成。 我想我花了不到一个小时。 产品寿命一小时是徒劳的。 但是，这是一个很大的收获。 我们现在就行动，我们开始做。 抱怨遗留代码很容易，也很容易一步步进行改进。 但是，抱怨不会解决问题。

知道何时停止 (Know when to stop)

We’re finally engaged in this refactoring. We want to do it well. We may want to do something perfect. Or to rewrite everything. But the important thing is to start improving, in small pieces, and to do it regularly. It is easier to be regular by doing small refactoring. With time, it will become an automatism. I make a change here, I will take this opportunity to improve there. The overall quality of the project will gradually increase.

我们终于参与了这种重构。 我们要做好。 我们可能想做一些完美的事情。 或重写一切。 但是重要的是要逐步改进并定期进行改进。 通过小的重构，使规则变得更容易。 随着时间的流逝，它将成为一种自动化。 我在这里进行更改，我将借此机会在那里进行改进。 项目的整体质量将逐步提高。

The goal is not to make something perfect. It would take too long. In some cases, the legacy is so huge that many adjustments have to be made. Unfortunately, some changes are long and complex. Breaking dependencies. Changing the code structure. And what is perfect code? We can always improve and do things differently. The design of the code may annoy you, but that’s okay, it’s better than before.

目的不是使事情变得完美。 会花太长时间。 在某些情况下，遗留物是如此巨大，以至于必须进行许多调整。 不幸的是，某些变化是漫长而复杂的。 打破依赖关系。 更改代码结构。 完美的代码是什么？ 我们总是可以改进并以不同的方式做事。 代码的设计可能会让您烦恼，但这没关系，它比以前更好。

The goal is not to rewrite everything. That would be risky and also time-consuming. If we want to rewrite everything at one time, the work will be huge and probably risky. We can make big mistakes, screw up the refactoring. We can discover many problems along the way and take much more time than expected. Worse, we can give up before we’re even finished. All the work will then be wasted. The team or management may find it harder to trust us on other subjects. It’s best to focus on the part we want to improve at this moment.

目的是不重写所有内容。 那将是冒险的，也是费时的。 如果我们想一次重写所有内容，那么这项工作将是巨大的，并且可能会有风险。 我们可能会犯大错误，搞砸了重构。 我们一路上会发现许多问题，所花费的时间比预期的要多得多。 更糟糕的是，我们甚至可以在完成之前就放弃。 所有的工作将被浪费掉。 团队或管理层可能很难在其他主题上信任我们。 最好把重点放在我们现在要改进的部分上。

So we have to be able to stop at some point. Focus on small improvements. It’s already better than before. If we come back to it later, we can improve it again. Even in a more macro way. I hope that my refactoring of a small area of the RoadMapBlock is the first step to improving the whole thing. This work will continue and inspire other developers.

因此，我们必须能够在某个时候停止。 专注于小改进。 已经比以前更好了。 如果稍后再讨论，我们可以再次对其进行改进。 即使以更宏观的方式。 我希望对RoadMapBlock的一小部分进行重构是改善整个过程的第一步。 这项工作将继续并激励其他开发人员。

现在就开始 (Get started, now)

All improvements are interesting. From simple renaming or dead code removal to method extraction or restructuring. Improvements can be simple and done quickly. There is no excuse to avoid changing legacy code. There’s no need to rewrite everything or spend whole days on it.

所有的改进都很有趣。 从简单的重命名或无效代码删除到方法提取或重组。 改进既简单又Swift。 没有任何借口避免更改遗留代码。 无需重写所有内容或花一整天的时间。

Make small improvements and be regular. This is one of the keys to reducing legacy gradually. Take advantage of a bug fix or a new feature to improve the surrounding code. Take action now.

进行小幅改进并保持规律。 这是逐步减少遗留物的关键之一。 利用错误修复或新功能来改进周围的代码。 现在就采取行动。

And you, what are you doing to improve legacy code? What are your strategies?

而您，您正在做什么来改进遗留代码？ 你有什么策略？

翻译自: https://medium.com/@chapuyj/take-every-opportunity-to-improve-legacy-code-b83137be53ed

调试代码遗留