这是一个哲学问题。我正在向我的软件添加一个小功能，我认为大多数用户都会使用它，但他们使用该软件的时间可能只有 10%。换句话说，该软件在没有它 3 个月的情况下还可以，但有 4 或 5 个用户要求它，我同意它应该在那里。
问题是，由于我正在使用的平台的限制（可能是我大脑的限制），“我能做的最好的”仍然有一些非关键但明显的错误 - 假设编码的功能是可用的但在某些情况下“有点不稳定”。
该怎么办？有 90% 的功能真的“聊胜于无”吗？我知道我会收到一些我无法修复的错误报告：我应该告诉客户什么？我应该接受未答复的功能请求或未答复的错误报告吗？
确保人们知道，你知道，存在问题。有错误。并为他们提供一种简单的方法来提供反馈。
与最初建议该功能的“4 或 5 个用户”进行“封闭测试”怎么样？
总会有未答复的功能请求和错误报告。发布它，但在可能的情况下包含一个包含“已知问题”和解决方法的自述文件。
您需要从用户的角度考虑这一点——这会减少挫败感吗？错误的代码通常比缺少功能更令人沮丧。
完美主义者可能会回答“不要这样做”。
商务人士可能会回答“做”。
我想平衡在哪里取决于你。如果错误不严重，我会倾向于将功能放在那里。大多数用户不会以与您相同的方式看待您的软件。你是一个工匠/艺术家，这意味着你比普通人更挑剔。
有什么方法可以让 4 到 5 个请求该功能的人获得测试版？然后，一旦你得到他们的反馈，就可能清楚做出哪个决定。
如果现在需要一个功能，而不是一个有效的功能。您可能需要发货。
但是在这种情况下：
如果错误可能导致死亡或可能丢失用户的文件，则不要发布它。
如果错误可能导致应用程序自行崩溃，则将其与警告一起发送（自述文件或其他内容）。如果崩溃可能导致应用程序损坏他们正在使用此应用程序编辑的用户文件，则每次启动应用程序时都会显示警告，并提醒他们先备份文件。
如果错误会导致蓝屏死机，那么要非常小心将其发送给谁。
我不希望编码人员将已知问题交付给测试，更不用说发布给客户了。
请注意，我相信对错误的零容忍。有趣的是，我发现通常是开发人员/测试人员最热衷于消除所有错误——通常是项目经理和/或客户愿意接受错误。
如果您必须发布代码，请记录您知道的每个功能/错误，并承诺修复每个功能/错误。
您为什么不发布更多有关您正在使用的平台的限制的信息，也许这里的一些聪明人可以帮助您列出错误列表。
准确地记录不稳定并运送它。
确保用户可能会看到并理解您的不稳定文档。
您甚至可以与请求该功能的用户讨论决定：做一些市场调查。
只是因为你现在不能修复它，并不意味着你将来不能。事情会改变的。
将您现在拥有的内容标记为“测试版”并将其发送给那些要求它的人。获得他们对它的工作情况的反馈，解决他们抱怨的任何问题，然后你应该准备好将它推广给更大的用户群体。
尽早发布，经常发布，不断重构。
我的意思是，不要让它阻止你发货，但也不要放弃解决问题。
无法解决不稳定是代码库中存在问题的标志。花更多的时间重构而不是添加功能。
我想这取决于你的标准。对我来说，有缺陷的代码还没有准备好生产，所以不应该发布。您能否提供一个包含已知问题列表的测试版，以便用户知道在某些条件下会发生什么？他们从使用新功能中受益，但也知道它并不完美（使用他们自己的风险）。这可能会让请求该功能的 4 或 5 个客户暂时满意，从而让您有更多时间修复错误（如果可能）并稍后发布到生产环境中供大众使用。
只是一些想法取决于你的情况。
要看。关于错误，它们的严重性以及您认为修复它们需要付出多少努力。在截止日期以及您认为可以延长多少时间。关于其余代码以及客户可以用它做多少。
来自必须为其用户安装错误软件的人 - 不要在启用该功能的情况下发布它。
如果您记录它并不重要，最终用户会在他们第一次遇到该错误时忘记该错误，并且该错误将成为他们无法完成工作的关键。
您需要回答的一个重要问题是，根据您提出的设计，您的功能是否能够解决真正的业务需求。然后只需使实现与设计相匹配 - 通过将“错误”定义为不属于功能的预期行为的一部分（应该由设计涵盖）来使“错误”成为非错误。
这归结为一个非常真实的路径选择：一个错误是不是不能正常工作，不是预期行为和设计的一部分？还是仅当不按照预期行为工作时才出现错误？
我坚信后者；错误是不能按照预期工作的方式工作的事情。实现应该捕获设计，应该捕获业务需求。如果实现用于解决设计未涵盖的不同业务需求，则错误在于设计，而不是实现；因此它不是一个错误。
根据我的经验，前一种态度在程序员中是最常见的。这也是用户查看软件问题的方式。然而，从软件开发的角度来看，采用这种观点并不是一个好主意，因为它会导致您修复不是错误而是设计缺陷的错误，而不是重新设计解决方案以满足业务需求。
如果它没有破坏其他任何东西，为什么不发货呢？听起来您与客户的关系很好，所以想要这个功能的人会很高兴得到它，即使它不是完全在那里，而那些不想要它的人也不会在意。此外，您将获得大量反馈以在下一个版本中改进它！