解释重构

Question

问题

我的问题是你如何教授整理和重构代码的方法和重要性？

背景

我最近正在为一位同事进行代码审查。他们对长期以来的同事工作进行了一些修改。在新的更改过程中，我的同事试图重构项目，但一旦遇到崩溃或其他问题就放弃了（而不是追逐兔子找到问题的根源），因此重新实现了问题代码和在此基础上建立更多。这使得代码处理了大量的变通方法和幻数，所以我和他们一起坐下来重构它。

我试图解释我是如何识别我们可以重构的地方以及每次重构通常如何突出新区域。例如，有两个变量存储相同的信息 - 为什么？我猜想这是一个更大问题的解决方法，所以我拿出一个变量，把兔子赶到了洞里，发现了其他问题。这最终导致我们发现了一个问题，即我们多次循环相同的事情。这在很大程度上归因于使用魔术数字大小的数组来模糊正在做的事情 - 修复最初的“双变量”问题导致了这一发现（以及其他）。

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

我觉得坐在一起做这件事的过程对我自己来说是值得的（我要学习更多关于如何最好地向他人解释事情）和我的同事（他们更多地了解我们的代码和我们的编码实践）但是，经验让我想知道是否有更好的方法来教授重构过程。

......最后......

我明白什么需要或不需要重构，以及如何重构它是非常主观的，所以我想避开那个讨论，但我有兴趣了解其他人如何应对教授这项重要技能的挑战，如果其他人有类似的经历和他们从中学到的东西（无论是老师还是学生）。

Answer 1

与大多数编程一样，重构技巧来自实践和经验。认为可以教授它会很好，但必须学习 - 并且在不同环境中可以实现的学习量存在显着差异。

要回答你的问题，你可以用教学方式教授重构方法和良好的设计，这很好。但是，最终，你和我都知道达到一定程度只是通过长期艰苦的经历。

Answer 2

我不是100％理解你的问题，但我认为你可以自己参考需要重构的Code Smell。它包含很多你可以向其他人展示的例子。

以下是应该使用重构的list（代码气味列表）

Answer 3

如果你还没看过，马丁福勒有一本关于这个主题的优秀书籍Refactoring: Improving the Design of Existing Code。他详细介绍了如何以及为什么要对特定代码进行重构。

我犹豫甚至提到它，因为担心这本书的知识是由有人询问重构的，并且你会想，“呃，我的意思是除了福勒书。”但是嘿，你走了。 ： - ）

Answer 4

你没有提到测试。要“证明”重构不会破坏现有功能，您需要在进行重构之前进行现有测试或编写测试。

Answer 5

配对编程似乎是我解决这个问题的最好方法。这样，当我们正在处理真实的生产代码时，我们都会遇到一些无法正常反映的代码，我们会一起解决代码重构问题。这两个人充当了司机的良心，说要做正确的事而不是快速修复，反过来，他们都会在这个过程中了解好的代码。

重构可以是一门艺术，只需要练习。你做的越多，你就越好。继续研究Martin Fowler的Ractoring书中描述的方法，并使用你的工具（Resharper for Visual Studio folk）

Answer 6

构思重构的一种简单方法就是名称 - 就像你将一个公共变量从一个等式中分解出来一样：

xy + xz

变为

x(y + z)

已经考虑了x。重构代码是一回事，因为你找到了重复的代码或逻辑并将其分解出来。

Answer 7

听起来你的方法非常好。在流程结束时，您展示了如何发现并解决许多问题。出于教育目的，发明新的更改/增强/修复可能会很有趣。然后，您可以询问您的心理导师他们将如何使用旧的新代码库实现更改。希望他们会发现使用重构代码进行新的更改会更容易（或者更多的重构将是准备假设更改的最简单方法）。

Answer 8

我看到了几种不同的方法可以尝试教授重构：

给出类似教科书的例子。这里的一个缺点是你可能有一些人为的或简单的例子，为什么重构是有用的，不一定会在其他情况下发光。

重构现有代码。在这种情况下，你可以使用你要清理的现有遗留代码，或者开发中你自己的代码，并在可读性和易维护性方面显示各种各样的位之前和之后看看后面有多好。这可能是一个更好的练习，因为这是在一定程度上改进和增强的实时代码。

这不是某人可以立即获取的东西，需要时间，练习，努力和耐心，因为一些重构可能是针对个人偏好而不是因为代码以某种方式最佳运行。

Answer 9

教导某人在不自然时进行重构是一项艰巨的工作。根据我的经验，你最好的选择是和他们一起坐在办公室里并重构一些代码。当你这样做时，请保持一个“意识流”对话框。谈论你所看到的，为什么代码没有正确的味道，重构的选项，等等。你还应该确保他们做同样的事情。最重要的是传达改变代码的原因，而不是如何改变代码。任何体面的程序员都可以做出改变并让它发挥作用，但是需要技巧和经验才能说明为什么新解决方案比以前更好。