这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
软件开发只是一份工作
不要误解我，我非常喜欢软件开发。在过去的几年里，我写了一篇关于这个主题的博客。我在这里花了足够的时间获得了5000声望点。我在一家初创公司工作，通常每周工作60个小时，工资比我作为承包商的工资要少得多，因为团队很棒，工作很有趣。
但从大局来看，这只是一份工作。
它的重要性低于许多事情，如家庭、女朋友、朋友、幸福等，也低于其他如果我有无限的现金供应，我宁愿做的事情，如骑摩托车、驾驶游艇或滑雪。
我认为有时候许多开发者忘记了开发只是让我们拥有生活中更重要的东西(通过做一些我们喜欢的事情来拥有它们)，而不是最终目标本身。
其他回答
异常应该只在真正异常的情况下使用
在我最近参与的项目中，异常的使用似乎非常猖獗。
这里有一个例子:
我们有拦截网络请求的过滤器。筛选器调用筛选器，筛选器的任务是检查请求是否具有某些输入参数并验证这些参数。你设置了要检查的字段，并且抽象类确保参数不为空，然后调用一个由你的特定类实现的screen()方法来进行更多的扩展验证:
public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{
//
if (!checkFieldExistence(req)){
return false;
}
return screen(req,resp,filterConfig);
}
checkFieldExistance(req)方法从不返回false。如果所有字段都不缺少，则返回true，如果缺少字段则抛出异常。
我知道这是一种糟糕的设计，但部分问题在于，这里的一些架构师认为，每次遇到意外情况时都需要抛出异常。
此外，我知道checkFieldExistance(req)的签名确实抛出了一个异常，这只是我们几乎所有的方法都这样做-所以我没有想到这个方法可能会抛出一个异常而不是返回false。直到我翻遍代码才发现。
开发80%是关于设计，20%是关于编码
我认为开发者应该将80%的时间用于设计细节，即他们将要构建的内容，而只有20%的时间用于编写他们所设计的内容。这将产生几乎零错误的代码，并在测试-修复-重新测试周期中节省大量时间。
过早地进入金属(或IDE)就像过早的优化，这被认为是万恶之源。深思熟虑的前期设计(我说的不一定是庞大的设计文档，简单的白板图纸也可以)会比编码和修改产生更好的结果。
删除类。 . net Framework中隐式处理异常的类的数量(类的方法)。和一个哑巴共事是很困难的。
在. net上开发不是编程。它只是把其他人的代码拼接在一起。
我的编码背景要求你了解硬件，这在我的行业中仍然是一个至关重要的要求，我认为高级语言只是简单地组装别人的工作。这并没有什么本质上的错误，但这是“编程”吗?
微软在为“开发人员”提供符号指令语法方面做了很多艰苦的工作。我现在似乎认识了越来越多的开发人员，他们在执行工作时似乎受到类的存在或不存在的限制。
我的观点来自于这样一个概念:作为一名程序员，你应该能够在你的平台允许的最低水平上编程。因此，如果您正在编写。net程序，那么您需要能够埋头苦干并找出解决方案，而不是依赖于其他人为您创建一个类。在我看来，这是一种懒惰，不符合“发展”的标准。
观点:开发者应该测试自己的代码
我曾经见过太多的垃圾交付给测试，但实际上并没有修复问题中的bug，导致了沟通开销，并助长了不负责任的实践。
