滥用“冻结代码”一词

Question

我很好奇社区是否认为在我们停止开发的情况下使用“Code Freeze”一词是可以接受的，除了测试和修复错误。

发展情况

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

问题

每一个版本我都会尝试纠正我的经理和同事，我们应该将其称为“功能冻结”，因为我们很快就会发现错误并提交代码来修复它们重试。但是他们仍然坚持称其为“Code Freeze”。有时我们仍然知道错误并宣布“冻结代码”。

维基百科的定义似乎与我同意here

分析

我怀疑将这些情况称为“代码冻结”是某种故意的Double Think，以便为利益相关者提供虚假的信心。或者我们假装处于“Code Freeze”状态，因为根据Scrum的说法，在每个sprint之后我们都应该有一个可发送的软件，这是我们对Scrum的期望。因此，我们必须将其称为Scrum所期望的而不是它的真实含义。

结论

我在分析这个吗？我只是发现忽视情况的现实是不健康的，应该放弃它，称之为不是或者解决根本问题。还有其他人有过与Code Freezes相似的经历吗？

Answer 1

  

我在分析这个吗？

是。

很可能，好吧。实际上，在冻结之后进行任何代码更改之前，您应该三思而后行。错误应该通过一些严重性测试，如果修复程序需要对代码库进行潜在危险的更改或者使已完成的测试无效，则更多。如果你没有那个，那么是的，你只是在欺骗自己。

但是如果你不想修复任何错误，那么冻结代码有点毫无意义：只需构建并运送它。

最重要的是，你们都明白标签的含义，而不是标签本身。一个大快乐的Humpty-Dumpty ...

Answer 2

我们使用术语“功能完成”。所有功能都是编码和功能，但我们正在进入测试通过，以确认没有错误。如果有错误，我们会找到它们，修复它们并重新测试。在我们对结果感到满意之后，我们就是“代码完成”。

Answer 3

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

Answer 4

有些人进入适应性和灵活的工程方法，如scrum，可能没有意识到你已经把自己变成了什么。

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

1. 如果您的项目预计在18个月内完成，但如果您每两个月可以使用越来越多的东西 - 为什么不每两个月发布一次功能，而不是等到18个月之后的盛大圣日，因为项目仍然是这样过去18个月。
2. 您的客户的要求可能会发生变化，因此让客户有机会经常改变主意，在为时已晚之前，会让客户感到兴奋。
3. 有人可能会在10个月后发布您的某个模块的开源模块，然后除了集成该模块之外，您不必做太多其他事情。

因此，scrum的动力学要求scrummers，或至少scrum master和/或项目经理/架构师模块化......模块化不够好;但要细化项目。

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

代码冻结是代码冻结。

如果您的代码冻结经常出现解冻延迟，那么您的Scrum主管和产品架构师无法正常沟通或无法正常工作。或许，试图给管理层留下深刻印象或默许他们正在使用一些名为敏捷编程的行业时尚是没有意义的。或者管理层需要聘请能够在团队技能范围内设计和细化项目的架构师和Scrum管理员，以及客户的期望和项目的技术限制。

我认为有一些管理元素和他们的scrum高手没有意识到一个优秀的架构师即使对于scrum环境并拒绝雇用一个人也是多么重要。一个能够倾听并与团队合作的优秀架构师对于scrumming过程非常宝贵，因为他/她必须不断调整架构以适应不断变化的粒度和期望。

我还认为管理元素及其scrum master属于编程领域的其他领域，因为像瀑布这样的开发周期较长的糟糕体验，因此他们认为scrum是为了在一个月内生成产品而且因此，对跨模块效应的细致调查并非真的有必要。他们坐下来，在空中弄湿手指，然后出现一个很好的冲刺。

如果您的团队遇到代码冻结的频繁解冻，您可能需要对整个项目进行代码冻结并重新考虑您的策略，并确定原因是由于您拒绝定义适合模块粒度的模块合同。或者你们是否根本定义了模块合同，以便当前难以使用模块的功能以使其他团队或模块能够继续使用。

你们有一个UML策略，有助于发现项目发布的预计功能，并允许您查看搁浅模块的影响，然后看看哪个模块需要关注以达到所需的产品发布级别？你是否参加了scrums和sprint，你没有UML的图片来展示你是如何进步或延迟的，以便你只是快乐地或盲目地碰撞自己？或者你的scrum主人会对是否有空间说，嗯...那个模块看起来很重要 - 实际上并没有清楚地了解哪个是与产品发布相关的最易绞合的模块。

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

Answer 5

是的，它被推翻了。 是的，这是用词不当。

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

应该发生的事情是，在版本控制中总会有一些可释放的系统版本，公司选择一个发货。

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

Answer 6

我参与了一个项目（瀑布），其中我们有功能冻结和代码冻结。

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

当QA认为产品处于可释放状态时（即他们不知道任何严重的错误），代码冻结就会出现。在最终测试周期之前，会宣布代码冻结（请记住，测试周期可能需要一周）。如果测试成功，则成为已发布的产品。如果失败则修复新的错误。这些签证由建筑师和管理人员监督，每条生产线的风险都有实际记录。然后再次启动测试周期。

摘要：功能冻结后，您只能检入错误修正。代码冻结后，您只能在特殊情况下办理登机手续。

Answer 7

在你的评论中，你提到了'sprint'这个词。这告诉我你可能正在使用Scrum（或任何其他敏捷）方法。在Scrum中你很难“冻结”任何东西:)灵活性，风险识别和缓解，最重要的是，在工程方面，持续集成在Scrum中很重要。

鉴于此，团队应该是跨职能的，代码将不断整合。因此，您可能没有“代码冻结”之类的内容。您只需在sprint结束时使用可释放的产品。它本应该连续测试，你应该已经有了你应该已经修复过的bug报告。

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

我个人不会在术语上分歧太多，而是术语背后的意图。当然，这个术语用于识别组织中SDLC的一个阶段。严格按照Scrum说话，它没有错误修复阶段。如果您正在使用一个或多个sprint来修复bug，那么这个术语可能意味着“sprint中不会包含任何功能积压，但只有bug修复”。这可以在sprint计划（和预先计划）会议中轻松处理，团队甚至不必担心术语。更好的是，这个术语/意图甚至不必超越产品负责人。

Answer 8

虽然“代码冻结”可能具有阴霾的含义，并且正如已经提到的那样，在考虑单个项目/发布时，它更恰当地称为“功能冻结”，它在更大的集成部署中占有一席之地，其中另一个实体负责用于打包和/或部署来自不同团队的多个软件版本。 “Code Freeze”让他们有时间确保环境排列整齐，并考虑所有包裹。 “代码冻结”也意味着只有“显示停止”的变化才会进入。其他所有内容都将在下一个维护版本中处理。

在一个完美的世界中，脚本测试将在此之前完成，并且有时间允许部署任何最后修复并重新测试。我还没有看到任何“globo-corp”发生这种情况。 （业务）测试人员在部署之前甚至在部署之后进行测试，并且“Code Freeze”成为他们加强努力并记录他们一直坐在的所有内容的信号。在某些情况下，这是他们开始测试的信号。

真的，“Code Freeze”只是商业代言“这里有Tygers”。 ; - ）

Answer 9

当我们编码冻结时，repo被锁定，希望所有的bug都被修复，你打算修复它们，并且测试人员在分支和构建到生产之前进行全面的测试。如果有任何未完成的错误安排在这次迭代中，那么潜在客户将在你的脖子上呼吸，直到它被关闭，或被视为非关键并推迟迭代。所以，是的，它真的冻结了。