这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
我们在这里使用我们构建的模型-视图-控制器框架进行了大量的开发。我经常告诉我的开发人员，我们需要违反MVC设计模式的规则，以使网站运行得更快。这对开发人员来说是很难接受的，他们通常不愿意牺牲设计良好的代码。但是性能是我们构建web应用程序的首要任务，所以有时我们不得不在框架上做出让步。
例如，视图层永远不应该直接与数据库对话，对吗?但是，如果你要生成大型报告，应用程序将使用大量内存来通过模型层和控制器层传递数据。如果你有一个支持游标的数据库，它可以让应用程序更快地直接从视图层访问数据库。
性能胜过开发标准，这是我有争议的观点。
其他回答
有时使用正则表达式从HTML中提取一些内容是可以的。严肃地说，与迟钝的解析器争论，或者使用快速的正则表达式，如/<a href="([^"]+)">/?这并不是完美的，但是您的软件可以更快地启动和运行，并且您可能还可以使用另一个正则表达式来验证提取的匹配是否确实看起来像一个URL。当然，这很俗气，而且可能在一些边缘情况下失败，但对于大多数使用来说已经足够好了。
基于大量的“如何使用正则表达式获取HTML?”的问题，几乎每天都在这里发布，而且事实上每个答案都是“使用HTML解析器”，这应该是有足够的争议性的。
尊重单一责任原则
乍一看，你可能不认为这是有争议的，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做所有事情时，他们通常会拒绝……所以对于孩子们，请不要再用我们经常看到的“什么都做”的方法了。
根据我得到的大量反馈，我最具争议的观点显然是，程序员并不总是读他们声称读过的书。这紧跟着我的观点，一个受过正规教育的程序员比一个自学成才的程序员更好(但不一定比另一个自学成才的程序员更好)。
在编程中使用的进程越多，代码就会变得越糟糕
I have noticed something in my 8 or so years of programming, and it seems ridiculous. It's that the only way to get quality is to employ quality developers, and remove as much process and formality from them as you can. Unit testing, coding standards, code/peer reviews, etc only reduce quality, not increase it. It sounds crazy, because the opposite should be true (more unit testing should lead to better code, great coding standards should lead to more readable code, code reviews should improve the quality of code) but it's not.
我认为这可以归结为我们称之为“软件工程”的事实，而实际上它是设计而不是工程。
以下数字可以证实这一说法:
From the Editor IEEE Software, November/December 2001 Quantifying Soft Factors by Steve McConnell ... Limited Importance of Process Maturity ... In comparing medium-size projects (100,000 lines of code), the one with the worst process will require 1.43 times as much effort as the one with the best process, all other things being equal. In other words, the maximum influence of process maturity on a project’s productivity is 1.43. ... ... What Clark doesn’t emphasize is that for a program of 100,000 lines of code, several human-oriented factors influence productivity more than process does. ... ... The seniority-oriented factors alone (AEXP, LTEX, PEXP) exert an influence of 3.02. The seven personnel-oriented factors collectively (ACAP, AEXP, LTEX, PCAP, PCON, PEXP, and SITE §) exert a staggering influence range of 25.8! This simple fact accounts for much of the reason that non-process-oriented organizations such as Microsoft, Amazon.com, and other entrepreneurial powerhouses can experience industry-leading productivity while seemingly shortchanging process. ... The Bottom Line ... It turns out that trading process sophistication for staff continuity, business domain experience, private offices, and other human-oriented factors is a sound economic tradeoff. Of course, the best organizations achieve high motivation and process sophistication at the same time, and that is the key challenge for any leading software organization.
请阅读文章，了解这些首字母缩写词的解释。
聪明的程序员很危险
我花了更多的时间试图修复“聪明”程序员编写的代码。我宁愿有一个优秀的程序员，而不是一个特别聪明的程序员，他想通过编写只有他(或她)才能解释的代码来证明自己有多聪明。
