哪个更好：发布有问题的功能还是根本不发布该功能？
这是一个有点哲学问题。 我正在向我的软件添加一个小功能，我认为大多数用户都会使用该功能，但他们使用该软件的次数可能只有 10%。 换句话说，这个软件没有它已经3个月了，但有4或5个用户要求它，我同意它应该存在。
问题是，由于我正在使用的平台的限制（可能还有我大脑的限制），“我能做的最好的”仍然有一些非关键但明显的错误 - 假设编码的功能是可用的但在某些情况下“有点不稳定”。
该怎么办？ 90% 的功能真的“比没有好”吗？ 我知道我会收到一些我无法修复的错误报告：我该如何向客户介绍这些问题？ 我应该接受未答复的功能请求或未答复的错误报告吗？
this is a bit of a philosophical question. I am adding a small feature to my software which I assume will be used by most users but only maybe 10% of the times they use the software. In other words, the software has been fine without it for 3 months, but 4 or 5 users have asked for it, and I agree that it should be there.
The problem is that, due to limitations of the platform I'm working with (and possibly limitations of my brain), "the best I can do" still has some non-critical but noticeable bugs - let's say the feature as coded is usable but "a bit wonky" in some cases.
What to do? Is a feature that's 90% there really "better than nothing"? I know I'll get some bug reports which I won't be able to fix: what do I tell customers about those? Should I live with unanswered feature requests or unanswered bug reports?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
来自必须为其用户安装有缺陷的软件的人 - 不要在启用该功能的情况下发布它。
如果您记录它并不重要，最终用户在第一次遇到该错误时就会忘记该错误，并且该错误将变得对他们无法完成工作至关重要。
Coming from someone who has to install buggy software for their users - don't ship it with that feature enabled.
It doesn't matter if you document it, the end users will forget about that bug the first time they hit it, and that bug will become critical to them not being able to do their job.
您需要回答的重要问题是，根据您提出的设计，您的功能是否能够解决真正的业务需求。 然后，只需使实现与设计相匹配即可 - 通过将“错误”定义为不属于功能的预期行为（应由设计涵盖），从而使“错误”成为非错误。
这归结为一个非常现实的路径选择：错误是否无法正常工作，不是预期行为和设计的一部分？ 或者只有当它不按照预期的行为工作时才是一个错误？
我坚信后者； bug 是那些没有按照预期工作方式工作的东西。 实施应该抓住设计，即抓住业务需求。 如果实现用于解决设计未涵盖的不同业务需求，那么有问题的是设计，而不是实现； 因此这不是一个错误。
根据我的经验，前一种态度在程序员中是最常见的。 这也是用户看待软件问题的方式。 然而，从软件开发的角度来看，采用这种观点并不是一个好主意，因为它会导致您修复不是错误的错误，而是设计缺陷，而不是根据业务需求重新设计解决方案。
The important question you need to answer is if your feature will solve a real business need given the design you've come up with. Then it's only a matter of making the implementation match the design - making the "bugs" being non-bugs by defining them as not part of the intended behaviour of the feature (which should be covered by the design).
This boils down to a very real choice of paths: is a bug something that doesn't work properly, that wasn't part of the intended behaviour and design? Or is it a bug only if if doesn't work in accordance to the intended behaviour?
I am a firm believer in the latter; bugs are the things that do not work the way they were intended to work. The implementation should capture the design, that should capture the business need. If the implementation is used to address a different business need that wasn't covered by the design, it is the design that is at fault, not the implementation; thus it is not a bug.
The former attitude is by far the most common amongst programmers in my experience. It is also the way the user views software issues. From a software development perspective, however, it is not a good idea to adopt this view, because it leads you to fix bugs that are not bugs, but design flaws, instead of redesigning the solution to the business need.
如果错误可能导致死亡或丢失用户的文件，那么就不要发布它。
如果错误可能导致应用程序自行崩溃，则在发布时附带警告（自述文件或其他内容）。 如果崩溃可能导致应用程序损坏用户正在使用此应用程序编辑的文件，则每次启动应用程序时都会显示警告，并提醒他们先备份文件。
如果错误可能导致 BSOD，那么请务必小心将其发送给谁。
If bugs can cause death or can lose users' files then don't ship it.
If bugs can cause the application to crash itself then ship it with a warning (a readme or whatever). If crashes might cause the application to corrupt the users' files that they were in the middle of editing with this exact application, then display a warning each time they start up the application, and remind them to backup their files first.
If bugs can cause BSODs then be very careful about who you ship it to.
如果它没有破坏其他任何东西，为什么不运送它呢？ 听起来你和客户的关系很好，所以那些想要这个功能的人会很高兴得到它，即使它不是完全实现，而那些不想要它的人也不会在意。 另外，您将获得大量反馈以在下一个版本中改进它！
If it doesn't break anything else, why not ship it? It sounds like you have a good relationship with your customers, so those who want the feature will be happy to get it even if it's not all the way there, and those who don't want it won't care. Plus you'll get lots of feedback to improve it in the next release!
确保人们知道，你也知道，存在问题。 存在错误。 并为他们提供一种提供反馈的简单方法。
与最初建议该功能的“4 或 5 个用户”进行“封闭测试”怎么样？
Make sure people know, that you know, that there are problems. That there are bugs. And give them an easy way to proide feedback.
What about having a "closed beta" with the "4 or 5 users" who suggested the feature in the first place?
总会有未答复的功能请求和错误报告。 发送它，但在可能的情况下包含包含“已知问题”和解决方法的自述文件。
There will always be unanswered feature requests and bug reports. Ship it, but include a readme with "known issues" and workarounds when possible.
您需要从用户的角度考虑这一点 - 这会减少挫败感？ 有缺陷的代码通常比缺少功能更令人沮丧。
You need to think of this from your user's perspective - which will cause less frustration? Buggy code is usually more frustrating than missing features.
完美主义者可能会回答“不要这样做”。
商界人士可能会回答“做吧”。
我想平衡点在哪里取决于你。 如果错误不严重，我会倾向于将该功能放在那里。 大多数用户看待您的软件的方式与您不同。 你是一名工匠/艺术家，这意味着你比普通人更挑剔。
有什么办法可以让 4-5 名请求该功能的人获得测试版吗？ 然后，一旦您得到他们的反馈，您就可以清楚做出哪个决定。
Perfectionists may answer "don't do it".
Business people may answer "do it".
I guess where the balance is is up to you. I would be swaying towards putting the feature in there if the bugs are non-critical. Most users don't see your software the same way you do. You're a craftsman/artist, which means your more critical than regular people.
Is there any way that you can get a beta version to the 4-5 people who requested the feature? Then, once you get their feedback, it may be clear which decision to make.
准确地记录并交付它。
确保用户可能看到并理解您的古怪文档。
您甚至可以与请求该功能的用户讨论该决定：做一些市场研究。
仅仅因为你现在无法修复它，并不意味着你将来也无法修复它。 事情会改变的。
Precisely document the wonkiness and ship it.
Make sure a user is likely to see and understand your documentation of the wonkiness.
You could even discuss the decision with users who have requested the feature: do some market research.
Just because you can't fix it now, doesn't mean you won't be able to in the future. Things change.
将您现在拥有的内容标记为“测试版”并将其发送给那些需要它的人。 获取他们对其工作效果的反馈，解决他们抱怨的任何问题，然后您应该准备好将其推广到更大的用户群体。
Label what you have now as a 'beta version' and send it out to those people who have asked for it. Get their feedback on how well it works, fix whatever they complain about, and you should then be ready to roll it out to larger groups of users.
尽早发布、经常发布、不断重构。
我的意思是，不要让它阻止你发货，但也不要放弃解决问题。
无法解决不稳定问题是代码库中存在问题的迹象。 花更多的时间重构而不是添加功能。
Ship early, ship often, constant refactoring.
What I mean is, don't let it stop you from shipping, but don't give up on fixing the problems either.
An inability to resolve wonkiness is a sign of problems in your code base. Spend more time refactoring than adding features.
我想这取决于你的标准。 对我来说，有缺陷的代码尚未准备好投入生产，因此不应发布。 您能否提供一个带有已知问题列表的测试版，以便用户知道在某些条件下会发生什么？ 他们从使用新功能中获益，但也知道它并不完美（使用新功能的风险由他们自己承担）。 这可能会让请求该功能的 4 或 5 个客户暂时满意，从而让您有更多时间修复错误（如果可能）并稍后向大众发布到生产环境。
只是根据您的情况提出一些想法。
I guess it depends on your standards. For me, buggy code is not production ready and so shouldn't be shipped. Could you have a beta version with a known issues list so users know what to expect under certain conditions? They get the benefit of using the new features but also know that it's not perfect (use that their own risk). This may keep those 4 or 5 customers that requested the feature happy for a while which gives you more time to fix the bugs (if possible) and release to production later for the masses.
Just some thoughts depending on your situation.
依靠。 关于错误、它们的严重性以及您认为修复它们需要付出多少努力。 关于最后期限以及您认为可以延长多少时间。 关于代码的其余部分以及客户端可以用它做多少事情。
Depends. On the bugs, their severity and how much effort you think it will take to fix them. On the deadline and how much you think you can stretch it. On the rest of the code and how much the client can do with it.
我不希望编码人员将已知问题交付到测试中，更不用说发布给客户了。
请注意，我相信对错误的零容忍。 有趣的是，我发现通常是开发人员/测试人员最热衷于消除所有错误 - 通常是项目经理和/或客户愿意接受错误。
如果您必须发布代码，请记录您所知道的每个功能/错误，并承诺修复每个功能/错误。
您为什么不发布更多有关您正在使用的平台的限制的信息，也许这里的一些聪明人可以帮助您记录错误列表。
I would not expect coders to deliver known problems into test let alone to release to a customer.
Mind you, I believe in zero tolerance of bugs. Interestingly I find that it is usually developers/ testers who are keenest to remove all bugs - it is often the project manager and/ or customer who are willing to accept bugs.
If you must release the code, then document every feature/ bug that you are aware of, and commit to fixing each one.
Why don't you post more information about the limitations of the platform you are working on, and perhaps some of the clever folk here can help get your bug list down.
如果需求是现在的功能，而不是有效的功能。 您可能需要运送。
但在这种情况下：
和后果（对用户而言）
和其他开发商）。
错误跟踪数据库。
确保编写了测试
在您之前突出显示错误
船。 这意味着当您
以后来修复bug，
你知道它们在哪里、是什么，
无需记住。
尽快。 你之前确实修复了错误
编写新代码，不是吗？
If the demand is for a feature NOW, rather than a feature that works. You may have to ship.
In this situation though:
and consequences (both to the user
and other developers).
bug tracking database.
make sure that tests are written
which highlight the bugs, before you
ship. This will mean that when you
come to fix the bugs in the future,
you know where and what they are,
without having to remember.
ASAP. You do fix bugs before
writing new code, don't you?