译者 | 刘汪洋
审校 | 重楼
多年来，我招聘了许多开发人员，其中一些人坚信代码需要频繁重构。然而，事实是，几乎每次他们完成重构并将代码交付给其他开发人员时，大家往往发现这些代码反而变得更难理解和维护。更糟糕的是，重构后的代码通常运行效率更低，且问题频发。
需要明确的是，重构本身并无不妥。它是保持代码库健康和可持续发展的关键。然而，不当的重构会带来负面影响，试图改进代码时出现的错误，往往会适得其反，这种情况并不罕见。
接下来，我们将探讨如何区分好的重构与不良重构，并讨论如何避免成为那个让团队成员都不愿意接触代码库的开发者。
在编程中，抽象既可能带来好处，也可能造成问题，关键在于何时以及如何应用。下面，我们将探讨一些常见的陷阱，并讨论如何避免这些问题。
我经常看到开发人员在重构过程中完全改变编码风格，这是最常见的错误之一。通常，这种情况发生在开发人员来自不同背景或对某种编程范式有强烈偏好的情况下。
让我们来看一个例子。假设我们有一段需要重构的代码：
重构前：
//
本文链接：http://www.28at.com/showinfo-26-112774-0.html好的代码重构 vs 坏的代码重构：如何做出正确选择？
声明：本网页内容旨在传播知识，不代表本站观点，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。
下一篇：QA已死：我们接下来走向何方？