与团队重命名，重构和打破变更的最佳实践

10

在团队环境中进行重构和重命名的最佳实践是什么？我提出了一些方案：

如果重构了通常引用的库，以对引用该库的任何库或项目进行重大更改。例如，任意更改方法的名称。
如果项目已重命名，则必须使用对它们的更新引用来重建解决方案。
如果通过引入文件夹并将现有项目或解决方案移至新位置来将项目结构更改为“更有条理”。

一些其他想法/问题：

是否应该像这样发生变化，还是所导致的疼痛表明结构出现了问题？
谁应该负责修复与重大更改相关的错误？如果开发人员进行了重大更改，那么他们应该负责进入受影响的项目并对其进行更新，还是应该提醒其他开发人员并提示他们进行更改？
这是可以按计划执行的事情还是应该尽可能频繁地执行？如果重构推迟的时间太长，则调解就变得越来越困难，但是由于一天中其他地方发生的变化，每天同时花费1小时来修复一个构建。
这是一个正式的沟通过程，还是有机的？

refactoring

— 大卫在达科他州
source

1

每次破坏构建时都要向每个人收取$ 1的费用……您会惊讶地发现，它遏制了一些粗心的错误。

— Berin Loritsch 2011年

+1是因为您的评论启发了3个出色的答案-不同的答案。

— Carl Manaster

13

您列出的每个方案都属于“已发布的API /代码”类别。这很难重构，因此不应轻易更改任何内容。相反，他应事先与有关各方协商计划的变更。至少与技术一样，这是一个政治问题。

因此，Martin Fowler对此的第一条建议是不要过早发布您的界面（项目名称和结构）。

但是，如果已经完成并且需要修复，则最好尝试以尽可能少的步骤进行必要的更改，以最大程度地减少对其他方的干扰。这与重构的原始概念相去甚远，但这是有充分理由的。

另外，如果可能，请考虑添加新方法（不推荐使用现有方法），而不要重命名现有方法。这样可以确保客户端代码不会中断，并为他们提供了一个过渡期，以便他们更新其代码以符合最新的API。缺点是它会使您的API复杂化。尽管状态只是暂时的，但是在安全删除不赞成使用的API方法之前，可能要花费相当长的时间（对于Java类库来说，是几年）。

— 佩特·托克（PéterTörök）
source

重构他人编写的代码时，不能使用Martin Fowler的建议（否则很好）。另外，我认为不赞成使用这些方法的开发人员应该提醒他的同事们不时使用新方法，而不必太烦人以加快转换速度。我的印象是，Java类库中不赞成使用的方法将始终存在，以实现向后兼容，但我可能是错的。

— blizpasta

@blizpasta，取决于所讨论的API有多少个客户端。如果您只有六个人，而且都在同一个部门内，那么在正常情况下，可能需要进行一些讨论和争论，并花费几个月的时间来完成过渡。如果您在全球拥有数百万个用户和数十亿个客户代码的LOC，那么是的，您很可能永远不会删除那些已弃用的方法。

— 彼得Török

5

通过两步重构，您几乎总是可以避免这些问题。第一步，引入新代码，并弃用旧代码。当所有团队都迁移到新代码后，删除旧代码。我还使用这种技术来逐步重构单个模块。这样，我可以限制在测试运行之间必须更改的代码量。

— 凯文·克莱恩
source

2

完成此操作后，通常可以更改旧代码以调用新代码。这使它成为存根方法，并为旧方法的客户端提供了（希望）改进的代码。

— BillThor

4

请注意，这是拥有运行测试的构建服务器的主要原因之一。

如果发生任何会破坏给定程序的事情，系统会尽快告知您，并且可以追究罪魁祸首并解决问题，而细节仍是新鲜的。