这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
引用已故的E. W. Dijsktra的话:
编程是应用数学中最难的分支之一;贫穷的数学家最好还是做纯粹的数学家。
计算机科学与计算机无关，就像天文学与望远镜无关一样。
我不明白一个人怎么能声称自己是一个合格的程序员，却不能解决像这个这样非常简单的数学问题。可能是一个CRUD猴子，但不是一个程序员。
其他回答
从长远来看，不需要探索所有形式的测试，QA也可以做得很好
很多地方似乎都有一种“方法”，即“我们怎么做”。这似乎隐含地排除了其他方法。
从长远来看，这是一个严重的问题，因为QA的主要功能是将错误归档并修复它们。
如果你不能找到尽可能多的bug，你就不能很好地做到这一点。例如，当您排除方法时，由于过于依赖黑盒，您开始忽略整个可发现的编码错误类别。这意味着，您正在使整个编码错误类无法修复，除非有人偶然发现它。
潜在的问题似乎往往是管理层+员工。有这个问题的管理者似乎对计算机科学和/或他们团队的价值主张有狭隘的想法。他们倾向于创建反映他们的方法的团队，以及测试方法的白名单。
我并不是说你可以或应该一直做所有的事情。让我们面对现实吧，对于给定的产品来说，一些测试方法只是在浪费时间。有些方法在产品成熟度的特定级别上更有用。但我认为，测试组织缺少的是挑战自己学习新事物的能力，并将其应用于整体绩效。
这里有一个假设的对话可以总结:
我:你测试了启动脚本10年，却对shell脚本及其工作原理一无所知?! 测试人员:是的。 我:权限? 测试人员:安装程序会这样做 我:平台，发布特定的依赖? 测试者:我们为此存档bug 我:错误处理? 测试人员:当错误发生时，客户支持会给我们发送一些信息。 我:好吧…(开始考虑在stackoverflow中写帖子…)
编程是如此简单，一个五岁的孩子都能做到。
编程本身并不难，这是常识。你只是在告诉计算机该做什么。你不是天才，别自以为是了。
软件不是一门工程学科。
我们不应该让计算机从数学系跑出来。
MS Access*是一个真正的开发工具，专业程序员可以毫无羞耻地使用它
仅仅因为某个平台吸引了自认为是程序员的黑客和秘书，就不应该玷污这个平台本身。每个平台都有其优点和缺点。
那些抱怨某些平台或工具或将其贬低为“玩具”的程序员更有可能对自己的手艺知之甚少，而不是他们的自我意识所说服的那样。对我来说，听到一个程序员抨击任何他们自己没有广泛使用过的环境是一种过度自信的表现。
*在这里插入任何恶意工具(VB, PHP等)。
这是我的:
“你不需要(文本)语法来表达对象及其行为。”
我赞同乔纳森·爱德华兹和他的潜台词项目——http://alarmingdevelopment.org/的观点
