我正在开展一个已经运行了很长一段时间的项目，我们正在准备最终版本的产品。
目前的测试工作已经发现系统中还有大约30个缺陷，但是我们没有时间来解决所有这些缺陷（我确信这是一种非常常见的情况）。
我与不同的人讨论了代码冻结是否应该继续进行。目前，我的经理希望保持代码冻结，但是要在冻结和释放之间的窗口中修复剩余的关键缺陷（大约5周）。我担心这不是一个实际的代码冻结，而是代码“搪塞”充其量。这些缺陷将由一组高级工程师进行分类，以确保只有剩余问题中的关键修复实际上得到了解决，但从初步看来，关键问题似乎占总缺陷缺陷的三分之二。
据我所知，冻结代码可为开发人员带来一些心理上的好处，例如为所有工作提供固定的结束日期。然而，这似乎完全否定了我的经理公开讨论将在“冻结之后”进行的修复。
我想知道是否有其他人有类似的经历，或者可以就如何处理这种情况的最佳方法提供一些建议。我开始认为没有人在他们说要去的那天实际冻结他们的代码库。
我们计划在代码冻结日从subversion中进行分支，以确保产品的最终发布版本与开发中继隔离，因此我不太担心会影响更改的问题该产品的发布版本。
谢谢，
Aidos
编辑：我认为解释我的经理人思维的最好方法是，它不是真正的代码冻结，更多的是“功能冻结”，但是因为所有的功能已经在产品中存在了一段时间我认为这是一个粗略的过度简化。EDIT2：我要感谢大家的出色答案，不幸的是我只能标记一个有用的，尽管到目前为止所有7个答案都非常有帮助。
答案 0 :(得分：6)
这是一种平衡行为。
一方面，有一个代码冻结期是很好的，但另一方面，没有人愿意运送产品的关键问题，足以让客户离开。
如果问题非常严重，如果是我的产品，没有代码冻结会阻止我修复它们。
祝你好运！答案 1 :(得分：4)
我认为实际的代码冻结是不可能的。通常，当代码冻结发生时，会发生更密集的测试。那又怎样？找到的所有问题都是下一版本的文件？如果您发现问题非常糟糕以至于关键功能无效，该怎么办？
你必须有办法处理每个问题/错误。因为大多数优秀的开发人员都很懒惰（意见），分支\标记并强制开发人员将他们的更改合并或复制到2个地方将停止大多数他们试图做出不是100％必要的改变。从那时起，您需要处理每个错误/问题。他们每个人都必须按照以下方式加权：问题是什么，问题影响到什么，重新发布最终版本需要多少天。每个问题的成本效益比。只有这样才能做出明智的决定。
答案 2 :(得分：2)
在这种情况下，我能想到的是避免出现问题，
If bug not fixed
you will be in trouble;
if codefreeze === true
fix your local version;
update the dev version on SVN;
goto manager;
state the severity of the bugs;
follow her direction because she already got a plan;
答案 3 :(得分：2)
代码冻结通常意味着所有当前已知的错误都无法修复。 （并且希望不言而喻，没有添加任何新功能）。如果在冻结期间发现错误，它们会添加新信息，并且根据分类视图，代码可能需要暂时“解冻”以修复错误。希望在代码冻结期间进行的更改都经过仔细审核。
据估计，三分之一的错误修复引入了随机严重性的新错误。代码冻结使您有时间将未知错误（可变严重性）“转换”为已知错误的已知错误。
真正的“代码冻结”，没有任何东西可以改变是没有意义的 - 如果你发现了一个主要的错误怎么办？你不能忽视它。
答案 4 :(得分：0)
在我们的案例中，当我们启动alpha（主分支暂时处于休眠状态）时，我们正在进行分支，并且当我们确定已完成修复缺陷时，我们在第一个客户发货之前编码冻结（不再提交）。
过去，我曾在一家公司工作过，代码冻结确实意味着功能冻结（不再增加功能）和分支。然后，我们正在研究缺陷。
我不会将您描述的内容称为代码冻结，而是更多地创建一个包装分支，您可以在其中详细说明并准备好您的代码以供发布。
答案 5 :(得分：0)
AFAIK“Code Freeze”实际上是无意义的，意思是“新代码冻结”。这样做的目的是调试的稳定性，错误修复不包含在冻结中，因为它们不是新代码，而是对旧代码的修复。
我们更倾向于使用术语“向下工具”，因为当你真的真的意味着放弃代码时。
答案 6 :(得分：0)
你的冻结真的是代码冻结还是功能冻结？你的问题并不是100％清楚。
话虽如此，我同意上述关于分支和合并的评论。这允许您和您的开发人员使用该分支来修复您知道的错误以及将在未来几周内发布的错误。然后，它允许您以受控方式将固定的任何关键错误集成到主（冻结）行中。
通过这种方式，您可以在不引入太多新缺陷的情况下解决最严重的问题。积分和回归测试在这里很重要。