这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
一旦发现缺陷就改正。不仅仅是“严重程度1”的缺陷;所有的缺陷。
建立一种部署机制，使用户可以立即使用应用程序更新，但允许他们选择何时接受这些更新。与用户建立直接的沟通机制，使他们能够报告缺陷，将他们的经验与更新联系起来，并提出改进建议。
With aggressive testing, many defects can be discovered during the iteration in which they are created; immediately correcting them reduces developer interrupts, a significant contributor to defect creation. Immediately correcting defects reported by users forges a constructive community, replacing product quality with product improvement as the main topic of conversation. Implementing user-suggested improvements that are consistent with your vision and strategy produces community of enthusiastic evangelists.
其他回答
从长远来看，开源软件的成本更高
对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。
当你考虑到质量的不一致性，可变的可用性和UI/UX，互操作性和标准的困难，增加的配置，相关的培训和支持需求的增加，开源的总拥有成本要比商业产品高得多。
精通技术的程序员类型接受开源的解放并与之一起运行;他们“得到它”，可以采用它，并定制它，以满足他们的目的。另一方面，主要是非技术性的，但需要软件来运行他们的办公室、网络和网站的企业正在冒着痛苦的风险，并在时间损失、生产力和(最终)支持费用方面付出沉重的代价，以及/或一起放弃实验的成本。
我有两个:
设计模式有时是糟糕程序员编写糟糕代码的一种方式——“当你有一把锤子时，整个世界看起来都像钉子”的心态。如果有什么我讨厌听到的是两个开发人员通过模式创建设计:“我们应该使用命令与facade…”
不存在所谓的“过早优化”。你应该在你觉得这样做太痛苦之前对你的代码进行分析和优化。
编程既不是艺术也不是科学。这是一门工程学科。
这不是艺术:编程当然需要创造力。这并不能让它成为艺术。代码的设计和编写是为了正常工作，而不是为了情感上的感动。除了空格之外，出于美观原因更改代码会破坏代码。虽然代码可以很漂亮，但艺术不是主要目的。
这不是科学:科学和技术是不可分割的，但编程属于技术范畴。编程不是系统的学习和观察;它是设计和实现。
这是一门工程学科:程序员设计和构建东西。优秀的程序员为功能而设计。他们了解不同实现选项的利弊，并选择适合他们正在解决的问题的实现选项。
我敢肯定有些人喜欢解析文字，将艺术和科学的定义扩展到包括编程，或将工程限制为机械机器或硬件。查字典。此外，“计算机编程艺术”是艺术的另一种用法，指的是一种技能或工艺，如“对话的艺术”。编程的产物不是艺术。
观点:大多数代码都很糟糕，因为这是程序员想要的。
间接地，我们一直在培育一种极具创造力的文化。这并不是说我不认为解决问题具有创造性元素——它确实存在——只是它与绘画之类的事情根本不一样(参见保罗·格雷厄姆的著名文章《黑客和画家》)。
If we bend our industry towards that approach, ultimately it means letting every programmer go forth and whack out whatever highly creative, crazy stuff they want. Of course, for any sizable project, trying to put together dozens of unrelated, unstructured, unplanned bits into one final coherent bit won't work by definition. That's not a guess, or an estimate, it's the state of the industry that we face today. How many times have you seen sub-bits of functionality in a major program that were completely inconsistent with the rest of the code? It's so common now, it's a wonder anyone cause use any of these messes.
复杂，复杂，丑陋的东西只会变得更糟，更不稳定。如果我们正在建造一些实体的东西，地球上的每个人都会说我们的东西是多么丑陋和糟糕，但由于它或多或少被虚拟隐藏起来，我们能够逃脱一些我们物种所见过的最糟糕的制造过程。(你能想象一辆车有四个不同的人用四种不同的方式设计了四个不同的轮子吗?)
但可悲的是，这一切中有争议的部分是，绝对没有理由这样做，除了历史上的文化倾向于更多的自由和更少的组织，所以我们保持了这种方式(可能变得更糟)。软件开发是一个笑话，但它是一个笑话，因为这是程序员想要的(但永远不会承认这是真的，“管理层的阴谋”对大多数人来说是一个更好的理由)。
我们还会搬起石头砸自己的脚多久，才会幡然醒悟，意识到我们才是握着枪、指着枪、扣动扳机的人?
保罗。
最好的程序员在调试器中跟踪所有代码并测试所有路径。
嗯…OP说有争议!
