这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
很快我们就会在一个没有 数据库。 AOP和依赖注入是的GOTO 21世纪。 开发软件是一种社交活动 活动，而不是技术活动。 乔尔有一个博客。
其他回答
牛仔程序员做得更多。
我一生都在创业的氛围中度过。如果没有牛仔编码员，我们将浪费无尽的周期来确保事情做得“正确”。
正如我们所知，预测所有问题基本上是不可能的。牛仔编码员会迎头撞上这些问题，并被迫比那些试图预见所有问题的人更快地解决它们。
不过，如果你是牛仔编码，你最好在其他人维护意大利面之前重构它。,)我所知道的最好的方法是使用持续重构。他们完成了大量的工作，不浪费时间试图预测未来，并通过重构成为可维护的代码。
过程总是阻碍一个优秀的牛仔，不管它有多敏捷。
当涉及到软件设计和开发时，设计模式是一种浪费时间的行为。
不要误解我的意思，设计模式是有用的，但主要是作为一种交流载体。它们可以非常简洁地表达复杂的思想:工厂、单例、迭代器……
但它们不应该作为一种开发方法。开发人员经常使用一系列基于设计模式的类来构建他们的代码，而在可读性和性能方面，更简洁的设计会更好。所有这些都带有一种幻想，即单个类可以在它们的域之外被重用。如果一个类不是为重用而设计的，或者不是接口的一部分，那么它就是一个实现细节。
设计模式应该被用来为组织特性命名，而不是用来规定必须编写代码的方式。
(这本来是有争议的，记得吗?)
QA应该比开发人员更了解代码(间接地)。QA通过发现开发人员不希望发生的事情而获得报酬，他们经常这样做。(顺便说一句，我是一名非常看重优秀QA人员的开发者。很少)。
世界需要更多的goto
人们虔诚地避免goto，除了“我的教授告诉我goto不好”之外，没有其他理由。它们有一个目的，可以在很多地方极大地简化生产代码。
也就是说，在你所编写的99%的代码中，它们都是不必要的。
尊重单一责任原则
乍一看，你可能不认为这是有争议的，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做所有事情时，他们通常会拒绝……所以对于孩子们，请不要再用我们经常看到的“什么都做”的方法了。
