testing - 滥用术语“代码冻结”

Question

我只是好奇社区是否认为在我们停止开发（除了测试和修复错误）的情况下使用术语“代码冻结”是可以接受的。

发展情况

我们刚刚完成第三次也是最后一次冲刺，随后将进行“代码冻结”和 2 周的 Q/A 测试。这是一个大版本，一些组件的开发已经超越了所有 3 个冲刺。从历史上看，即使我们称之为“代码冻结”，我们仍然会提交代码来修复错误。

问题

每个版本我都会尝试纠正我的经理和同事，我们应该称之为“功能冻结”，因为很明显，一旦我们开始大量测试，我们就会发现错误并提交代码来修复它们。但他们仍然坚持称其为“代码冻结”。有时我们仍然有已知的错误并声明“代码冻结”。

分析

我怀疑将这些情况称为“代码冻结”是某种故意的双重思考，旨在为利益相关者提供虚假的信心。或者我们假装处于“代码冻结”状态，因为根据 Scrum 在每个 sprint 之后我们应该有一个可交付的软件，这是我们遵循 Scrum 的期望。所以我们必须称它为 Scrum 所期望的，而不是它真正的名字。

结论

我是不是分析过度了？我只是发现忽略现实情况是不健康的，应该放弃将其称为不是的东西或解决根本问题。有没有其他人在代码冻结方面有类似的经历？

score 18 · Accepted Answer

我是不是分析过度了？

是的。

我们可能会。实际上，在冻结后进行任何代码更改之前，您应该三思而后行。错误应该通过一些严重性测试，如果修复需要对代码库进行潜在危险的更改或使已完成的测试无效，则更是如此。如果你不这样做，那么是的，你只是在自欺欺人。

但是，如果您不打算修复任何错误，那么冻结代码是毫无意义的：只需构建并发布它。

归根结底，重要的是你们都了解标签的含义，而不是标签本身。一个大快乐的矮胖子……

score 12 · Accepted Answer

我们使用术语“功能完成”。所有功能均已编码且功能齐全，但我们正在进入测试阶段以确认没有错误。如果有错误，我们将找到它们，修复它们并重新测试。在我们对结果感到满意后，我们就完成了“代码完成”。

score 3 · Accepted Answer

实际上，我认为他们的解释更正确。对我来说，功能冻结将停止引入新功能，但目前正在开发的功能可能会继续完成，或者您可以安排一些重构工作以消除技术债务而不产生新功能。代码冻结会停止所有新开发，包括重构——唯一允许的新代码是修复在 QA 期间发现的错误。后者似乎是您的团队正在做的事情。

score 3 · Accepted Answer

一些采用像 scrum 这样的自适应和敏捷工程方法的人可能没有意识到你自己陷入了什么。

敏捷工程的原因是向您的客户发布现在可用的任何东西，并逐渐建立其可用性和功能。

如果您的项目预计在 18 个月内完成，但如果您可以每 2 个月有更多可用的东西 - 为什么不每两个月发布一次功能，而不是等到 18 个月后的盛大圣日，因为无论哪种方式，项目仍将持续 18 个月.
您的客户的要求可能会发生变化，因此让您的客户有机会经常改变主意，以免为时已晚，从而使客户兴奋不已。
有人可能会在 10 个月后发布您的模块之一的开源模块，然后您无需做太多其他事情，只需集成该模块即可。

因此，scrum 的动态需要 scrum 人员，或者至少是 scrum 主管和/或项目经理/架构师来模块化......模块化还不够好；但细化项目。

您必须将模块细化到合适的大小，并为每个模块提供合同接口规范，以便在模块内管理模块内的更改。如果您的模块本身或由于其他模块的依赖无法满足合约接口，您必须冻结代码以使您能够广播合约接口版本 1，以便其他团队可以继续，尽管功能少于预期在下一个通用产品版本中。

代码冻结是代码冻结。

如果您的代码冻结经常遇到解冻延迟，那么您的 Scrum Master 和产品架构师没有沟通或没有正确地完成他们的工作。也许，试图让您的管理层相信他们正在使用一种称为敏捷编程的行业时尚，这可能是没有意义的。或者管理层需要聘请架构师和 Scrum Master，他们能够根据团队的技能以及客户的期望和项目的技术限制来设计和细化项目。

我认为有些管理人员和他们的 scrum master 甚至没有意识到一个好的架构师对 scrum 环境的重要性，并且拒绝雇用一个。一个能够倾听并与团队合作的优秀架构师对于 Scrumming 过程是无价的，因为他/她必须不断地调整架构以适应不断变化的粒度和期望。

我也认为有一些管理元素和他们的 scrum master 属于编程世界的另一个谱系，由于像瀑布这样的较长开发周期的糟糕经历，他们因此认为 scrum 是为了在一个月内生产出一个产品，因此进行了细致的调查进入跨模块效果并不是真正必要的。他们坐下来，在空中弄湿手指，然后进行了一次出色的冲刺。

如果您的团队经常遇到代码冻结的问题，那么你们可能需要对整个项目进行代码冻结并重新考虑您的策略，并查看原因是由于您拒绝定义适合模块粒度的模块合约。或者你们是否完全定义了模块合同，以便当前可以精简卡住模块的功能，以使其他团队或模块能够继续。

你们是否有一个 UML 策略来帮助发现项目发布的预计功能并允许您查看搁浅模块的影响，然后查看需要关注哪个模块才能达到所需的产品发布级别？您是否参加了 Scrums 和 sprint，并且没有 UML 的图片来显示您的先进或延迟程度，以至于您只是愉快地或盲目地颠簸自己？或者您的 Scrum 主管是否会对房间说“是”或“否”，嗯……那个模块似乎很重要——实际上并没有清楚地了解哪些是与产品发布相关的最可绞合的模块。

通过逐步冻结模块来实现产品发布代码冻结。一旦一个模块完成，就会进行产品测试以确保该模块满足其合同，并且该模块被代码冻结为 2.1 版。尽管 2.2 的该模块的工作取得了进展，但整个项目不应依赖于 2.2，而应依赖于 2.1。该策略是在测试产品版本以及产品版本是否应该缩减其功能时，尽量减少需要解冻合同的模块数量。如果渐进式模块化冻结对您的开发团队没有帮助……要么产品非常复杂，而您的管理层对实现正确发布的迭代次数预期不足，要么模块化架构和策略需要认真重新考虑。

score 3 · Accepted Answer

我从事过一个项目（瀑布），其中我们有功能冻结和代码冻结。

功能冻结意味着错误修复期的开始。还为新版本创建了新分支，以便我们可以实现功能，即这是公司开始开发新版本的时间点。没有实现新功能，只修复了错误。

当 QA 认为产品处于可发布状态（即他们不知道任何严重的错误）时，代码冻结就会出现。在最终测试周期之前，会宣布代码冻结（请记住，测试周期可能需要一周时间）。如果测试成功，这将成为发布的产品。如果失败，则修复新的错误。这些签到由架构师和管理人员监督，每条线路的风险都被记录在案。然后再次开始测试循环。

摘要：功能冻结后，您只能签入错误修复。代码冻结后，您只能在特殊情况下签入。

score 2 · Accepted Answer

是的，多虑了。是的，用词不当。

如果代码没有损坏/乱七八糟，你就不会碰它，如果是，那么你会修复它。这与您没有处于代码冻结状态完全相同。是的，它是反模式的“需求冻结”或“集成中断”。这是停止在下一个版本中包含新功能的点，这在销售/营销/客户支持方面很有价值。但他们可能应该称之为“预发布”。

应该发生的是，在版本控制中总是有一些系统的可发布版本，公司会选择一个来发布。

“代码冻结”的精益名称是“浪费”。

score 2 · Accepted Answer

在您的评论中，您提到了“冲刺”这个词。这告诉我你可能正在使用 Scrum（或任何其他敏捷）方法。在 Scrum 中，您几乎不会“冻结”任何东西 :) 灵活性、风险识别和缓解，最重要的是，就工程而言，持续集成在 Scrum 中非常重要。

鉴于此，团队应该是跨职能的，并且代码将不断集成。因此，您可能没有“代码冻结”之类的东西。在 sprint 结束时，您只有一个可发布的产品。它应该已经被持续测试并且你应该已经得到了你应该已经修复的错误报告。

嗯，这是理论。然而，好的 Scrum 团队离理论并不远，因为 Scrum 主要是关于原则的。没有太多的规则。

I personally won't split too many hairs on the terminology, but the intention behind the term. Most certainly, the term is used to identify a stage in the SDLC, in your organization. Speaking strictly as per Scrum, it doesn't have a bug fix phase. In case you're dedicating one or more sprints to fix bugs, then this term can mean, "no feature backlogs will be included in the sprint, but only bug fixes". This can be easily handled at the sprint planning (and pre-planning) meeting(s) and the team doesn't even have to worry about the terminology. Even better, this terminology/intention doesn't even have to go beyond the Product Owner.

score 1 · Accepted Answer

虽然“代码冻结”可能有一个模糊的含义，并且如前所述，在考虑单个项目/版本时更恰当地是“功能冻结”，但它确实在更大的集成部署中占有一席之地，其中另一个实体负责打包和/ 或部署来自不同团队的多个软件版本。“代码冻结”让他们有时间确保环境排列整齐并考虑所有包。“代码冻结”还意味着除了“显示停止”更改之外什么都没有。其他所有内容都将在下一个维护版本中处理。

在一个完美的世界中，脚本测试会在此之前完成，并且有时间部署任何最后的修复和重新测试。我还没有看到任何“全球公司”发生这种情况。（业务）测试人员在部署之前甚至之后进行测试，“代码冻结”成为他们加紧努力并记录他们一直坐在的所有内容的信号。在某些情况下，这是他们开始测试的信号。

真的，“代码冻结”只是“这里有 Tygers”的商业代言。;-)

score 0 · Accepted Answer

当我们冻结代码时，repo 被锁定，希望所有你想要修复的 bug 都已修复，并且测试人员在分支和构建到生产之前进行另一轮测试。如果本次迭代有任何未解决的错误，那么潜在客户将在你的脖子上喘不过气来，直到它被关闭，或者被认为是非关键的并推迟迭代。所以，是的，它真的被冻结了。

testing - 滥用术语“代码冻结”

9 回答 9

Related

Reference