1

我正在使用 2 个非常不同的应用程序。

App #1 是一个网络应用程序，我可以直接访问 FTP，因此修复错误非常容易。Cat A 错误通常会在第二天修复。这里没有问题。

App #2 是一个石油业务文档控制应用程序，我们必须经过两个验收测试阶段——最终用户测试和系统测试。在此阶段之后发现的任何错误都将保留到下一个版本，通常是 2-3 个月。每个新的发布包都是巨大的成本。很难向最终用户解释他们必须忍受一些错误，直到下一个版本。

您如何处理无法立即修复的严重错误？

4

6 回答 6

7

我修复错误的速度越快，我发现需要修复的错误就越多。

于 2009-06-23T01:04:40.693 回答
2

管理允许您修复错误的速度与成本管理直接相关，直到错误被修复。

我是一个单人队。我和我的虫子之间没有任何关系:)

于 2009-06-23T01:01:36.643 回答
2

在我个人看来，您所描述的情况是一个非常深层次的结构性问题，应该在项目开始之前就已经解决了。每个程序员都应该知道至少一个人可以在需要时直接推送更改，并且必须明确执行此操作的过程。老实说，存在潜在数据丢失的安全或数据库问题呢？我的意思是当然，如​​果你不能解决它直接通知工作人员并告诉他们“请不要这样做”，但老实说，最好的方法是尽快解决这个问题。我在终端应用程序中遇到过类似的情况，在按两次按钮后程序简单地退出工作。修复是微不足道的，但没有人被允许修复它，而且依赖于这个东西运行的所有人都需要花费数小时。要求重要更改的捷径！

于 2009-06-23T01:22:04.577 回答
1

这实际上取决于组织规模、系统规模、系统重要性和错误影响的组合，例如：

一人商店或低影响系统（最快 - 上面的 App#1）

修复错误的时间 =发现错误的时间 +修复代码的时间 +部署到生产的时间

大型组织或重要系统（最长 - 上面的 App#2）

修复 bug 的时间 =发现 bug的时间 +记录和确定 bug 优先级的时间 +估算成本的时间 +批准修复工作的时间 +设计修复的时间 +记录修复的时间 +修复代码的时间 +记录测试计划的时间+测试修复时间+回归测试时间 +性能/负载测试时间 +计划和批准部署时间 +部署修复时间

编辑：换一个灯泡需要多少微软员工？是关于该主题的有趣读物。

1：见http://blogs.msdn.com/ericlippert/archive/2003/10/28/53298.aspx

于 2009-06-23T01:36:17.917 回答
0

答案将是一个人对生产环境的访问量与所涉及的生命或金钱数量的比率。

于 2009-06-23T01:22:15.870 回答
0

变通方法。

我以前的经验是，用户认为某个功能由于错误而死，通知我们，等到错误修复，然后告诉我们在该部分的停机期间，他们一直在将信息输入到他们的旧 Excel 版本中应用程序（从 Excel 迁移 Oracle APEX），然后很好地询问了我们再次从他们的 excel 应用程序动态插入数据的周转时间。周转时间比原始错误的停机时间要长。

于 2009-06-23T01:29:24.203 回答