向管理层解释重构

该如何向 CEO 及其他没有技术背景的人们证明重构的价值呢？

在一场主题为“ Refactoring Justification Language ”的讨论中，来自 BigVisible 的敏捷教练 Adam Sroaka 说到“重构是必要的，因为需求不可避免地会发生变化，这样代码也不可避免地要适应这种变化。当遵循良好设计原则的代码发生变化后，他们就不再遵循这些原则了。重构是这样一种技术：一旦代码修改后，我们可以通过重构不断改进代码的设计”。

来自 CollabNet 的 Scrum 认证培训师 Michael James 则关注于重构与测试优先的编程模式。他说，一开始编写的新代码总是有些凌乱，这样他和他的搭档就需要时间清理代码。

XP 创始人之一的 Ron Jeffries 在一篇名为“ Why is Refactoring a Must ”的文章中说到，假如我们无法在为期两周的 Sprint 中交付 Scrum 项目所需的所有必要的基础设施，那么我们就得准备重构了，以此进行改进，否则我们迎来的将是一团乱麻，这会严重阻碍项目团队的进度。他还指出，Scrum 与任何其他的敏捷方法的一个基本假定是需求会发生变化。如果需求发生了变化，那么就需要重构代码以清理留下来的乱摊子。

Michael James 在“Refactoring Justification Language”的讨论中补充到：即便需求不会发生变化，重构也是必不可少的，因为我们一开始所编写的代码肯定不会是完美的。

Mark Woyna 建议到，我们应该看看汽车产业：每年，制造商们都会对汽车进行众多细小的更新，但只有很少一部分是最终用户的需求。有时，他们会修改某个零件以提高使用寿命或是降低花费。

此次报道表明：我们甚至都没必要和管理层讨论重构这个话题。重构应该是我们职业道德的一部分。每天早上的第一件事就应该是重命名或是提取方法，这就好像是工作之前的热身一样。

查看英文原文： Explaining Refactoring to Management