重构 Cringely

最近，罗伯特·克林格利的一篇文章在重构社区引起了小小的轰动，因为他批评了重构。Phlip 在重构邮件列表上对回应进行了总结，用一种异常克制的语气说：“……他听起来像个‘怀疑论者’，写书评却没打算读。”

当然，克林格利对重构的理解程度并不清楚，尽管他确实理解了重构是一个行为保持转换过程的关键点。他所做的是强调了一些重构被不恰当使用的方式。

一种误用是重构不会改变的代码。重构的全部意义在于它改善了现有代码的设计。设计良好的代码的价值在于它更容易改变。因此，您重构的是您预计将来会更改的代码。重构稳定的代码毫无意义。

另一个例子是他提到的一个重构团队进入其他团队的代码并对其进行重构。这是我愿意花钱避免的“服务”。程序员应该只重构自己的代码，而不是在其他东西中乱搞。XP 团队使用集体代码所有权，鼓励任何人都可以重构团队代码库中的任何代码，但这只适用于该团队的代码。一个团队在没有通知任何人的情况下四处游荡重构其他团队的代码的想法，当然不是我推荐的做法。

最后，他抱怨重构被用来涵盖任何形式的代码更改。与其他情况一样，我完全同意他的观点。长期以来，我一直对人们将重构作为重组事物的同义词感到厌烦。重构是一个非常特殊的过程，它使用一系列小的语义保持转换来更改代码库。这是一个非常特殊和有纪律的过程。还有其他方法可以重组代码，无论是否有益，这些都不是重构。

所以总的来说，听起来我同意克林格利所说的大部分内容。这是真的，邮件列表上的评论也是如此。总的来说，人们感到恼火是因为克林格利为了指责时尚而歪曲了重构。

我当然不同意克林格利的观点，他认为 80% 的重构是浪费时间，软件经理应该停止重构以节省资金。重构的意义在于改进设计使更改更容易，因此重构提高了生产力。当然，程序员需要判断重构工作是否会带来回报，而这并非易事。但我一次又一次地看到人们浪费时间绕过设计糟糕的代码，用只会让情况更糟的补丁来解决问题。重构是一种摆脱这种特定死亡螺旋的方法——这就是我认为它是一种如此有价值的技术的原因。