这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
显然，IDE应该在浪费时间编译之前检查他们是否可以链接他们创建的代码，这是有争议的
但我的观点是，我不应该编译无数行代码才意识到Windows对我试图创建的文件有一个锁，因为另一个程序员有一些奇怪的线程问题，要求他在dll不应该被使用后延迟卸载3分钟。
其他回答
程序员和开发人员是有区别的。例如:程序员编写分页逻辑，开发人员在页面上集成分页。
当为数据访问层创建单元测试时，数据应该直接从DB中检索，而不是从模拟对象中检索。
考虑以下几点:
void IList<Customer> GetCustomers()
{
List<Customer> res = new List<Customer>();
DbCommand cmd = // initialize command
IDataReader r = cmd.ExecuteQuery();
while(r.read())
{
Customer c = ReadFiledsIntoCustomer(r);
res.Add(c);
}
return res;
}
在GetCustomers的单元测试中，对cmd.ExecuteQuery()的调用应该实际访问DB还是应该模拟它的行为?
我认为，如果以下情况成立，您不应该模拟对DB的实际调用:
存在一个测试服务器和模式。 模式是稳定的(意味着您不期望对其进行重大更改) DAL没有聪明的逻辑:查询是简单地构造的(config/stored procs) 去虹膜化的逻辑很简单。
从我的经验来看，这种方法的最大好处是你可以尽早与DB进行交互，体验“感觉”，而不仅仅是“外观”。它为您省去了许多事后的麻烦，并且是熟悉模式的最佳方法。
许多人可能会争辩说，一旦执行流跨越了进程边界，它就会成为一个单元测试。我同意它有它的缺点，特别是当数据库不可用，然后你不能运行UT。
然而，我相信在许多情况下这应该是一件有效的事情。
删除类。 . net Framework中隐式处理异常的类的数量(类的方法)。和一个哑巴共事是很困难的。
一个文件一个类
谁在乎呢?我更喜欢把整个程序包含在一个文件中，而不是一百万个不同的文件。
“评论是谎言”
注释不能运行，而且很容易被忽略。最好是用清晰的、由单元测试说明的重构代码来表达意图。(当然是编写TDD的单元测试…)
我们不写注释，因为它们很冗长，而且模糊了代码中真正发生的事情。如果你觉得需要注释——找出代码中不清楚的地方，然后重构/编写更清晰的测试，直到不需要注释……
．.． 我从极限编程中学到的东西(当然，假设你已经建立了清理代码的团队规范……)
