这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
我有争议的观点是John Carmack(游戏邦注:代表作有ID Software, Quake等)并不是一个优秀的程序员。
不要误解我的意思，在我看来他是一个非常聪明的程序员，但当我注意到quake源代码中的“#define private public”这一行后，我不禁认为他是一个无论如何都能完成工作的人，但在我的定义中，他不是一个好程序员:) 这个观点让我陷入了很多激烈的讨论;)
其他回答
如果你没有读过手册页，你就不是一个真正的程序员。
没有“放之四海而皆准”的发展方法
我很惊讶这是一个有争议的观点，因为在我看来这是常识。然而，在热门博客上有许多文章都在推广“一刀切”的开发方法，所以我认为我可能只是少数。
我所见过的被吹捧为任何项目的正确方法的东西——在了解任何关于它的信息之前——像使用测试驱动开发(TDD)、领域驱动设计(DDD)、对象关系映射(ORM)、敏捷(大A)、面向对象(OO)等等，等等，包括从方法到架构到组件的一切。当然，这些都是很有市场价值的首字母缩写。
人们甚至似乎在他们的博客上贴上徽章，比如“我是测试驱动的”或类似的东西，就好像他们严格坚持单一的方法，不管项目的细节是什么，实际上是一件好事。
它不是。
选择正确的方法、体系结构和组件，等等，是应该在每个项目的基础上完成的事情，不仅取决于您正在从事的项目的类型及其独特的需求，而且还取决于与您一起工作的团队的规模和能力。
在编程中使用的进程越多，代码就会变得越糟糕
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.
请阅读文章，了解这些首字母缩写词的解释。
代码==设计
我不喜欢复杂的UML图和无穷无尽的代码文档。在高级语言中，您的代码应该是可读和可理解的。复杂的文档和图表对用户来说并不友好。
这里有一篇关于代码即设计的文章。
软件工程师不应该和计算机科学家一起工作
他们的区别: se关心代码的可重用性，而CSs只关心代码 se关心性能，而CSs只想现在就把事情做好 se关心整个结构，而CSs则不在乎 .．.
