这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
程序员把他们自己的(有限的)编程语言视为神圣不可侵犯的宗教。
有趣的是，程序员几乎像宗教信徒一样对待这些讨论:不允许批评，(通常)不允许客观的讨论，(通常)基于非常有限或缺乏的知识和信息进行争论。为了确认，只需阅读之前的答案，尤其是评论。
同样有趣的是，另一个确认:根据“给我一个有争议的意见”这个问题的定义，任何有争议的意见都不应该被投反对票——实际上恰恰相反:越有争议越好。但我们的程序员是如何反应的:就像巴甫洛夫的狗一样，对不喜欢的意见投反对票。
PS:为了公平起见，我给其他一些人点了赞。
其他回答
从长远来看，开源软件的成本更高
对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。
当你考虑到质量的不一致性，可变的可用性和UI/UX，互操作性和标准的困难，增加的配置，相关的培训和支持需求的增加，开源的总拥有成本要比商业产品高得多。
精通技术的程序员类型接受开源的解放并与之一起运行;他们“得到它”，可以采用它，并定制它，以满足他们的目的。另一方面，主要是非技术性的，但需要软件来运行他们的办公室、网络和网站的企业正在冒着痛苦的风险，并在时间损失、生产力和(最终)支持费用方面付出沉重的代价，以及/或一起放弃实验的成本。
关系数据库对于web应用程序来说非常糟糕。
例如:
螺纹评论 标签云 用户搜索 维护记录视图计数 提供撤销/修订跟踪 多步的向导
没有“放之四海而皆准”的发展方法
我很惊讶这是一个有争议的观点，因为在我看来这是常识。然而，在热门博客上有许多文章都在推广“一刀切”的开发方法，所以我认为我可能只是少数。
我所见过的被吹捧为任何项目的正确方法的东西——在了解任何关于它的信息之前——像使用测试驱动开发(TDD)、领域驱动设计(DDD)、对象关系映射(ORM)、敏捷(大A)、面向对象(OO)等等，等等，包括从方法到架构到组件的一切。当然，这些都是很有市场价值的首字母缩写。
人们甚至似乎在他们的博客上贴上徽章，比如“我是测试驱动的”或类似的东西，就好像他们严格坚持单一的方法，不管项目的细节是什么，实际上是一件好事。
它不是。
选择正确的方法、体系结构和组件，等等，是应该在每个项目的基础上完成的事情，不仅取决于您正在从事的项目的类型及其独特的需求，而且还取决于与您一起工作的团队的规模和能力。
观点:SQL是代码。这样对待它
也就是说，就像c#、Java或其他喜欢的对象/过程语言一样，开发一种可读且可维护的格式化样式。
我讨厌看到草率的自由格式SQL代码。如果您在页面上看到两种样式的花括号时都尖叫，那么当您看到自由格式化的SQL或模糊JOIN条件的SQL时，为什么不尖叫呢?
开发团队应该更多地按照技术/架构层而不是业务功能来划分。
我来自一个开发者拥有“从网页到存储过程的一切”的普遍文化。因此，为了在系统/应用程序中实现一个功能，他们将准备数据库表模式，编写存储procs，匹配数据访问代码，实现业务逻辑和web服务方法，以及web页面接口。
And guess what? Everybody has their own way to doing things! Everyone struggles to learn the ASP.NET AJAX and Telerik or Infragistic suites, Enterprise Library or other productivity and data layer and persistence frameworks, Aspect-oriented frameworks, logging and caching application blocks, DB2 or Oracle percularities. And guess what? Everybody takes heck of a long time to learn how to do things the proper way! Meaning, lots of mistakes in the meantime and plenty of resulting defects and performance bottlenecks! And heck of a longer time to fix them! Across each and every layer! Everybody has a hand in every Visual Studio project. Nobody is specialised to handle and optmise one problem/technology domain. Too many chefs spoil the soup. All the chefs result in some radioactive goo.
Developers may have cross-layer/domain responsibilities, but they should not pretend that they can be masters of all disciplines, and should be limited to only a few. In my experience, when a project is not a small one and utilises lots of technologies, covering more business functions in a single layer is more productive (as well as encouraging more test code test that layer) than covering less business functions spanning the entire architectural stack (which motivates developers to test only via their UI and not test code).
