您如何处理重构和合并需求之间的紧张关系? [英] How do you handle the tension between refactoring and the need for merging?

问题描述

发布新版本时，我们的政策是在VCS中创建一个分支并将其交给我们的质量检查团队.当后者发出绿光时，我们标记并释放我们的产品.该分支将保留(仅)错误修复，以便我们可以创建技术版本.这些错误修复程序随后将合并到主干中.

Our policy when delivering a new version is to create a branch in our VCS and handle it to our QA team. When the latter gives the green light, we tag and release our product. The branch is kept to receive (only) bug fixes so that we can create technical releases. Those bug fixes are subsequently merged on the trunk.

这期间，主干看到了主要的开发工作，并且可能会进行重构更改.

During this time, the trunk sees the main development work, and is potentially subject to refactoring changes.

问题在于，需要有一个稳定的主干之间存在紧张关系(这样，错误修复程序才能成功合并-如果将代码例如提取到另一种方法或移至另一种方法，通常是无法做到的)类)，并在引入新功能时需要对其进行重构.

The issue is that there is a tension between the need to have a stable trunk (so that the merge of bug fixes succeed -- it usually can't if the code has been e.g. extracted to another method, or moved to another class) and the need to refactor it when introducing new features.

我们的政策是在经过足够的时间并且分支足够稳定之前，不进行任何重构.在这种情况下，您可以开始在中继上进行重构更改，并且必须在中继和分支上手动提交错误修复程序.

The policy in our place is to not do any refactoring before enough time has passed and the branch is stable enough. When this is the case, one can start doing refactoring changes on the trunk, and bug-fixes are to be manually committed on both the trunk and the branch.

但这意味着开发人员必须等待相当长的时间才能在干线上提交任何重构更改，因为这可能会破坏从分支到干线的后续合并.而且必须手动将错误从分支移植到主干是很痛苦的.在我看来，这阻碍了发展……

But this means that developpers must wait quite some time before committing on the trunk any refactoring change, because this could break the subsequent merge from the branch to the trunk. And having to manually port bugs from the branch to the trunk is painful. It seems to me that this hampers development...

您如何处理这种紧张局势?

How do you handle this tension?

谢谢.

推荐答案

这是一个实际的实际问题.如果您需要支持多个版本并为每个版本分支，则情况会变得更糟.更糟糕的是，如果您也拥有真正的R& D分支机构.

This is a real practical problem. It gets worse if you have several versions you need to support and have branched for each. Even worse still if you have a genuine R&D branch too.

我倾向于允许主干以正常速度运行，而不是坚持不停，因为在商业发布时间很重要的环境中，我永远都不会争辩说我们应该让代码稳定下来(您是说您以不稳定状态释放了它?").

My preference was to allow the main trunk to proceed at its normal rate and not to hold on because in an environment where release timings were important commercially I could never argue the case that we should allow the code to stabilise ("what, you mean you released it in an unstable state?").

关键是要确保在将错误迁移到主分支时，已为错误修复创建的单元测试已经过渡.如果您对新代码所做的更改确实只是在重构，那么旧测试应该同样有效.如果您所做的更改已不再有效，那么您无论如何都不能移植您的修补程序，而您需要让别人认真考虑一下新代码流中的修补程序.

The key was to make sure that the unit tests that were created for the bug fixes were transitioned across when the bug was migrated into the main branch. If your new code changes are genuinely just re-factoring then the old tests should work equally well. If you changes are such that they are no longer valid then you can't just port you fix in any case and you'll need to have someone think hard about the fix in the new code stream.

在解决了此类问题很多年后，我得出结论，您可能至少需要4个代码流才能提供适当的支持和覆盖，并需要一组相当严格的流程来管理它们之间的代码.有点像能够绘制4种颜色的地图的问题.

After quite a few years managing this sort of problem I concluded that you probably need 4 code streams at a minimum to provide proper support and coverage, and a collection of pretty rigorous processes to manage code across them. It's a bit like the problem of being able to draw any map in 4 colours.

我从来没有找到关于这个主题的任何真正好的文献.它将不可避免地与您的发布策略以及您与客户签署的SLA链接起来.

I never found any really good literature on this subject. It will inevitably be linked to your release strategy and the SLAs that you sign with your customers.

附录:我还要提到，有必要将合并的分支作为特定的里程碑写入主分支的发布时间表.如果您有一群努力工作的开发人员执行其工作实现功能，请不要低估将分支机构整合在一起可能需要的工作量.

Addendum: I should also mention that it was necessary to write the branch merging as specific milestones into the release schedule of the main branch. Don't under-estimate the amount of work that might be entailed in bring your branches together if you have a collection of hard-working developers doing their job implementing features.

这篇关于您如何处理重构和合并需求之间的紧张关系?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！