我很好奇您的偏好和想法是关于尽可能在幕后进行尽可能少的测试以及尽可能快地滚动尽可能多的新功能，并在生产网站上进行测试或对其进行故障排除的想法地狱，直到他们防弹，然后释放给公众。
答案 0 :(得分：5)
也许中间立场可能更合适。如果有的话，你的“品牌”会受到很大影响：
在这两种情况下，你都不太可能长期保持业务。
我经营的商店认识到软件会有一些错误。所有高严重性错误必须在发布之前修复，所有低严重性错误必须有一个计划，以便在发布后进行修复。
软件维护（基本上是修复bug并回答客户问题）是我们开发过程的重要部分。
此外，修复错误的“成本”变得更多，因为所述错误的发现从开发人员转移到了客户。
修复我在单元测试中发现的错误只涉及我，但如果我的内容被延迟，它会影响其他人。
在系统测试期间发现错误意味着其他阶段肯定会延迟，因为代码必须返回并在再次升级到系统测试之前再次进行更改和单元测试。
在您的软件上线后查找错误是另一个痛苦的世界，涉及与客户的沟通，多个管理报告行都希望在后端留下他们的启动印象，并通过进行任何错误修复所有阶段，否则就会产生不利影响 - 在第九个地狱圈中一个特别令人讨厌的地方是为那些在修复他们的bug时引入又一个的开发者保留的。
答案 1 :(得分：3)
使用“尽可能少的测试”将代码分发到生产服务器以使其更快地运行，这让自己陷入了痛苦的生活。你真正建议的是让你的用户为你测试你的系统，这将是一个测试计划，但即使你到达那里之前，你应该已经进行了很好的测试，并确信应用程序有效，否则你“我不会长期留住很多用户。
从开发人员的角度来看，我很乐意发布我相信按计划工作的代码。从用户的角度来看，无论在开发周期的早期阶段，我都不希望使用不断下降的应用程序。
如果尚未准备好，请不要将其释放。
答案 2 :(得分：3)
这取决于管理层的愿望而不是客户的愿望。如果选择“你可以让它工作，或者你可以在周五工作”，那么普通的目标和目标爱好者将更喜欢星期五。
如果您确实有选择，请将其保留至工作状态。你会为自己和其他所有人节省时间和麻烦。
Time(do it right) < Time(do it again) + Time(correct database) + Time(explain and apologise)
（软件工程基本法。）
答案 3 :(得分：2)
答案 4 :(得分：1)
这取决于客户的痛苦程度和期望，以及面向客户的员工如何管理他们的“反馈”。
如果您的客户希望快速进入大批量生产，在激烈竞争的非常紧迫的时间表，以及您提供的产品（想想手机等消费类电子产品），那么他们根本不会感谢您任何惊喜。他们非常害怕不得不召回数十万台进行升级。
也许你正在向正在做研究的人，大学部门或类似人员提供服务，他们可能会屈服于你的交付，以达到一个不适合的目的。他们不介意，甚至可能期待，问题，并乐于找到解决方法。他们可能会对这些功能感到兴奋，并且只要他们发现您正在倾听他们的反馈，就会原谅您的错误。
与我合作过的最熟练的客户工作人员能够判断客户需要多长时间才能注意到我们提供的交付存在的不足，需要多长时间才能让我们的工程师填补空白，并意识到客户注意到问题我们有补丁的时间。客户提前交货，因此合同是安全的，不会因为错误而感到不便，对支持感到满意，一切都是幸福的世界。这是一个棘手的电话;如果你没有发布任何东西，直到它完美，你将永远不会有一个客户，因为有人会总是削弱你，但是过早地发布一些东西并且令人失望，那么当机会出现时你将会被替换。判断修补程序开发时间错误，您的客户会感到不快。
简而言之，这是关于开放式沟通的事情，关于虚张声势，欺骗和欺骗的事情，以及关于判断知道该做什么以及什么时候做什么的判断。
答案 5 :(得分：0)
我认为这取决于您的用户群。例如，我选择在我的linux盒子上使用尖端和不太稳定的功能。但我认为总的来说，特别是在网页开发中，生成网页浏览通常是一个高优先级，你想要适合大多数人的工作，这是稳定的。
答案 6 :(得分：0)
如果您正在与少数人进行测试或alpha测试，请确保。但是，如果这是一般公众或您的企业使用的代码，那么不。 Buggy代码对程序员反映不佳，而且我知道当某些东西崩溃或意外行为时，它往往会让人烦恼。
因此，我更愿意发布经过深思熟虑的代码，这些代码可能没有那些给人们带来糟糕体验的代码所带来的花边和口哨。
然而，一个脚注是你必须知道什么时候足够了。每个程序员都可以花费很多时间来处理每一行代码，并说“好吧，如果我把它移到这里，我可以获得0.001％的速度提升”或者同样的思路。相信我，我也有这个问题，并且往往会痴迷。说出一些“足够好”的技巧是很难学的，但在我看来这绝对是必要的。