这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
从长远来看，不需要探索所有形式的测试，QA也可以做得很好
很多地方似乎都有一种“方法”，即“我们怎么做”。这似乎隐含地排除了其他方法。
从长远来看，这是一个严重的问题，因为QA的主要功能是将错误归档并修复它们。
如果你不能找到尽可能多的bug，你就不能很好地做到这一点。例如，当您排除方法时，由于过于依赖黑盒，您开始忽略整个可发现的编码错误类别。这意味着，您正在使整个编码错误类无法修复，除非有人偶然发现它。
潜在的问题似乎往往是管理层+员工。有这个问题的管理者似乎对计算机科学和/或他们团队的价值主张有狭隘的想法。他们倾向于创建反映他们的方法的团队，以及测试方法的白名单。
我并不是说你可以或应该一直做所有的事情。让我们面对现实吧，对于给定的产品来说，一些测试方法只是在浪费时间。有些方法在产品成熟度的特定级别上更有用。但我认为，测试组织缺少的是挑战自己学习新事物的能力，并将其应用于整体绩效。
这里有一个假设的对话可以总结:
我:你测试了启动脚本10年，却对shell脚本及其工作原理一无所知?! 测试人员:是的。 我:权限? 测试人员:安装程序会这样做 我:平台，发布特定的依赖? 测试者:我们为此存档bug 我:错误处理? 测试人员:当错误发生时，客户支持会给我们发送一些信息。 我:好吧…(开始考虑在stackoverflow中写帖子…)
其他回答
如果我有争议的话，我不得不说乔恩·斯基特并不是万能的。
好的建筑是生长出来的，而不是设计出来的。 经理们应该确保他们的团队成员总是在低于他们的技术水平的情况下工作，无论这个水平是什么。当人们在自己的舒适区工作时，他们就能写出更高质量的代码。
我觉得我们应该放弃C。它太旧了!但是，老狗还是叫得更响了!!
关系数据库对于web应用程序来说非常糟糕。
例如:
螺纹评论 标签云 用户搜索 维护记录视图计数 提供撤销/修订跟踪 多步的向导
管理者无所不知
根据我的经验，经理通常不是通过了解代码来达到这个目的的。不管你怎么跟他们说，它太长了，不对或者太贵了。
还有一个是继第一个之后的:
没有时间把事情做对，但总有时间再做一遍
一位很好的工程师朋友曾经说过，他很生气地描述了这样一种情况:管理层把他的估计减半了，从他那里得到了一个半途而废的版本，然后给了他两倍的时间来返工，因为它失败了。在商业软件世界中，这是一件相当常见的事情。
今天在尝试配置一个只有web接口的路由器时，我想到了一个问题:
网页界面是为傻瓜准备的
上一个固件版本的CLI非常好。这个版本有一个web界面，试图从无知的IT机器人那里隐藏所有网络的复杂性，甚至不能得到正确的vlan。
