解释重构 [英] Explaining refactoring

问题描述

我的问题是，您如何教整理和重构代码的方法和重要性?

My question is how can you teach the methods and importance of tidying-up and refactoring code?

我最近正在为一位同事进行代码审查.他们对长期的同事工作进行了一些修改.在进行新的更改期间，我的同事曾尝试重构项目，但是一旦遇到崩溃或其他问题(而不是追赶兔子找到问题的根源)就放弃了，因此重新实现了问题代码并在此之上构建更多.这使代码陷入了变通方法和魔术数字的纠结中，因此我与他们坐下来进行重构.

I was recently working on a code review for a colleague. They had made some modifications to a long-gone colleagues work. During the new changes, my colleague had tried to refactor items but gave up as soon as they hit a crash or some other problem (rather than chasing the rabbit down the hole to find the root of the issue) and so reimplemented the problem code and built more on top of that. This left the code in a tangle of workarounds and magic numbers, so I sat down with them to go through refactoring it.

我试图解释我如何确定我们可以重构的地方，以及每次重构通常如何突出新的领域.例如，有两个存储相同信息的变量-为什么?我猜想这是解决更大问题的一种解决方法，所以我取出一个变量，将兔子追到洞口，发现我们前进时发现了其他问题.最终导致发现一个问题，我们在同一问题上多次循环.这在很大程度上要归功于使用魔术数字大小的数组来混淆正在执行的操作-解决最初的双变量"问题导致了这一发现(及其他).

I tried to explain how I was identifying the places we could refactor and how each refactoring can often highlight new areas. For example, there were two variables that stored the same information - why? I guessed it was a workaround for a bigger issue so I took out one variable and chased the rabbit down the hole, discovering other problems as we went. This eventually led to finding a problem where we were looping over the same things several times. This was due in no small part to the use of arrays of magic number sizes that obfuscated what was being done - fixing the initial "double-variable" problem led to this discovery (and others).

当我与同事一起进行重构之旅时，很明显，她并不总是能够理解为什么我们进行了某些更改以及如何确定新功能是否与原始功能匹配，因此我花了一些时间来通过与早期版本进行比较并逐步完成纸上的更改来解释和证明每个更改.我还通过示例解释了如何判断重构选择是否是个坏主意，何时选择注释而不是代码更改，以及如何选择好的变量名.

As I went on this refactoring journey with my colleague, it was evident that she wasn't always able to grasp why we made certain changes and how we could be sure the new functionality matched the original, so I took the time to explain and prove each change by comparing with earlier versions and stepping through the changes on paper. I also explained, through examples, how to tell if a refactoring choice was a bad idea, when to choose comments instead of code changes, and how to select good variable names.

我觉得坐在一起做这件事的过程对我自己(我需要更多地了解如何最好地向他人解释事物)和我的同事(他们必须了解我们的更多代码和编码实践)，但是经验使我想知道是否有更好的方法来教授重构过程.

I felt that the process of sitting together to do this was worthwhile for both myself (I got to learn a bit more about how best to explain things to others) and my colleague (they got to understand more of our code and our coding practices) but, the experience led me to wonder if there was a better way to teach the refactoring process.

我了解到什么需要或不需要重构以及如何进行重构是非常主观的，因此我想避免进行这种讨论，但是我有兴趣了解其他人将如何应对教授这一重要技能的挑战，以及这里的其他人是否有类似的经历以及他们从中学到的东西(无论是作为老师还是作为学生).

I understand that what does or does not need refactoring, and how to refactor it are very subjective so I want to steer clear of that discussion, but I am interested to learn how others would tackle the challenge of teaching this important skill, and if others here have had similar experiences and what they learned from them (either as the teacher or the student).

推荐答案

像大多数编程一样，重构技能来自实践和经验.认为可以教，但必须学习，这很高兴-而且在不同环境下可以完成的学习量也存在很大差异.

Like most programming, refactoring skill comes with practice and experience. It would be nice to think it can be taught, but it has to be learned - and there is a significant difference in the amount of learning that can be accomplished in different environments.

要回答您的问题，您可以以教学的方式教授重构方法和良好的设计，这很好.但是，最终，您和我俩都知道只有通过长期的辛苦经验才能达到一定的水平.

To answer your question, you can teach refactoring methods and good design in a pedagogical fashion, and that's fine. But, ultimately, you and I both know attaining a certain level is only through long hard experience.

这篇关于解释重构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！