我见过许多列出了有关已知问题的详细信息的 API?如果存在已知问题,为什么要在修复之前将其公开?
是什么原因?死线?或者修复它会破坏其他东西?
注意:我不确定这个问题是否属于这里。因此,如果这不是一个有效的问题,请随时关闭。
我见过许多列出了有关已知问题的详细信息的 API?如果存在已知问题,为什么要在修复之前将其公开?
是什么原因?死线?或者修复它会破坏其他东西?
注意:我不确定这个问题是否属于这里。因此,如果这不是一个有效的问题,请随时关闭。
软件并不完美,等到每个问题都得到解决后再发布一些东西将导致一个没有软件的世界。
因为即使存在问题,该软件也是可用且有用的,并且因为用户宁愿早点拥有它而不是等待发布。因为它的开发人员希望尽早发布它会提供反馈。
总是有已知的问题。如果您在没有更多已知问题之前不发布,您将永远不会发布。有时,最好将一个主要工作的版本推出门外,并警告一些非关键问题。
通常,即使存在已知问题,较新的软件仍然比以前可用的版本更好。尤其是在处理库时,客户通常更愿意尽快交付有问题的代码,而不是等待他们不关心的问题得到修复。
已知问题通常会影响少数用户,其他所有人都可以真正使用新版本中的改进。此外,现有版本可能存在相同的问题,在这种情况下,不会向用户提供新的(已知)错误。所以,这真的是一场胜利。
有些问题也可能需要很长时间才能解决。
利润。
任何复杂的现实世界软件永远不会是完美的。然而,在某个点上它“足够好”,那就是发货的时候了。
真正的争论发生在决定什么水平的质量符合“足够好”的标准时。
有时你就是无法解决这些问题。
想象一下,您在浏览器中有一个 JS 脚本和一些您无法避免的错误。在修复该浏览器之前,您不会发布您的库,对吗?或者,您可以添加关于一个浏览器问题的“已知问题”注释并发布它。
否则你永远不会释放。
已知问题很好。引起麻烦的是未知的问题。
因为软件稳定。如果有一些已知问题不直接影响软件的日常使用并且可以通过补丁修复,那为什么不发布呢?
此外,还有期限和成本需要考虑,但显然后者并不真正适用于开源。
主要原因是上市时间
有时,发布有用的东西的好处比只有一些用户会被打动的问题更重要。
错误可能是次要的或严重的:S
如果它的影响很小(影响少数用户或者可能是内部的),那么这可能是一个原因。其他人可能是想要尽快推出市场的大人物,因此有时必须根据许多因素使事情变得不完整。
特别是对于开源项目,这使得大多数用户可以毫无问题地获得产品,同时也提高了对错误的认识,因此用户可以为代码做出贡献。
如果一个已知问题只影响一小部分潜在用户,那么它可能值得发布。
API 是 API 的实现者和使用 API 的程序员之间的契约。即使实现存在已知问题,最好发布 API 文档,以便程序员能够开始开发可以利用 API 的代码。据了解,实施的提供者将(最终)履行他们的合同,使实施与 API 完全一致。如果 API 仅在实现完美时才发布,那么应用程序开发人员将被迫浪费大量开发时间来提高生产力,即使仅基于 API 文档,他们也做不到实际测试代码呢。
“承诺”。
那更重要。
一旦交付日期最终确定(承诺),如果产品处于“可接受”级别,则必须放行。“完美”和“接受”的区别在于“已知问题”
大多数公司都有一个发布标准,可能看起来像 -
软件版本可能有一些小错误,其计数设置为限制 - 此类问题可能是次要 UI 问题。
软件发布可能有一些重大错误,其数量已设置为限制 - 尝试使发布没有此类错误,但如果它们仍然逃脱(由于不同的原因),那么他们不应该破坏产品并且有一些工作周围可以绕过它们。
软件发布不应有任何严重错误 - 如果发现任何严重错误,软件将不会发布。此类错误会破坏产品而没有任何解决方法。
同样,上述分类可能偏离目标,取决于公司及其所涉及的流程。
干杯
查看提前发布/经常发布政策的好处,例如用户的宝贵反馈。