这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
软件复用是优化软件开发的重要途径
不知怎的，软件重用一度流行，但后来失去了它的魅力，因为许多公司发现，仅仅写带有重用口号的powerpoint演示文稿实际上并没有帮助。他们认为软件重用“不够好”，无法实现他们的梦想。因此，它似乎不再流行了——它被许多项目管理新手所取代(例如敏捷)。
事实是，任何真正优秀的开发人员都会自己执行某种软件重用。我会说任何不做软件重用的开发人员都是糟糕的开发人员!
我亲身经历过，软件重用在多大程度上可以提高开发的性能和稳定性。当然，一组幻灯片和管理层的半心半意的坦白并不足以在一家公司充分发挥其潜力。
我已经链接了一篇关于软件重用的旧文章(见标题)。它最初是用德语写的，后来被翻译了——所以，如果它写得不好，请原谅。
其他回答
扩展方法是魔鬼的工作
Everyone seems to think that extension methods in .Net are the best thing since sliced bread. The number of developers singing their praises seems to rise by the minute but I'm afraid I can't help but despise them and unless someone can come up with a brilliant justification or example that I haven't already heard then I will never write one. I recently came across this thread and I must say reading the examples of the highest voted extensions made me feel a little like vomiting (metaphorically of course).
主要原因是增加了可读性、改进了oo性以及更好地连接方法调用的能力。
I'm afraid I have to differ, I find in fact that they, unequivocally, reduce readability and OO-ness by virtue of the fact that they are at their core a lie. If you need a utility method that acts upon an object then write a utility method that acts on that object don't lie to me. When I see aString.SortMeBackwardsUsingKlingonSortOrder then string should have that method because that is telling me something about the string object not something about the AnnoyingNerdReferences.StringUtilities class.
LINQ是这样设计的，链式方法调用是必要的，以避免奇怪和不舒服的表达式，来自LINQ的扩展方法是可以理解的，但一般来说，链式方法调用降低了可读性，并导致我们在混乱的Perl竞赛中看到的那种代码。
因此，简而言之，扩展方法是邪恶的。摆脱撒旦的枷锁，致力于自由扩展代码。
如果我有争议的话，我不得不说乔恩·斯基特并不是万能的。
我们在这里使用我们构建的模型-视图-控制器框架进行了大量的开发。我经常告诉我的开发人员，我们需要违反MVC设计模式的规则，以使网站运行得更快。这对开发人员来说是很难接受的，他们通常不愿意牺牲设计良好的代码。但是性能是我们构建web应用程序的首要任务，所以有时我们不得不在框架上做出让步。
例如，视图层永远不应该直接与数据库对话，对吗?但是，如果你要生成大型报告，应用程序将使用大量内存来通过模型层和控制器层传递数据。如果你有一个支持游标的数据库，它可以让应用程序更快地直接从视图层访问数据库。
性能胜过开发标准，这是我有争议的观点。
这里有一个多年来对我来说似乎是显而易见的，但对其他人来说却是一个诅咒:在“发布”版本中使用NDEBUG关闭C(或c++)断言几乎总是一个错误。(唯一的例外是时间或空间惩罚是不可接受的)。
原理:如果断言失败，则程序进入了一种状态
从未被检验过 开发人员无法为恢复策略编写代码 开发人员有效地将其记录为不可思议的。
然而，在某种程度上，“行业最佳实践”是，当涉及到客户数据的实时运行时，事情应该只是敷衍了事，期待最好的结果。
That (at least during initial design), every Database Table (well, almost every one) should be clearly defined to contain some clearly understanable business entity or system-level domain abstraction, and that whether or not you use it as a a primary key and as Foreign Keys in other dependant tables, some column (attribute) or subset of the table attributes should be clearly defined to represent a unique key for that table (entity/abstraction). This is the only way to ensure that the overall table structure represents a logically consistent representation of the complete system data structure, without overlap or misunbderstood flattening. I am a firm believeer in using non-meaningful surrogate keys for Pks and Fks and join functionality, (for performance, ease of use, and other reasons), but I beleive the tendency in this direction has taken the database community too far away from the original Cobb principles, and we jhave lost much of the benefits (of database consistency) that natural keys provided.
那么为什么不两者都用呢?
