这绝对是主观的，但是我想尽力避免它引起争论。我认为如果人们适当对待它可能是一个有趣的问题。
这个问题的想法来自我对“您讨厌自己喜欢的语言的五件事是什么？”的回答中的评论主题。问题。我认为默认情况下应该密封C＃中的类-我不会将问题放在问题中，但是我可能会写一个更完整的解释作为对此问题的答案。我对评论中的讨论热度感到惊讶（目前有25条评论）。
那么，您持有哪些有争议的意见？我宁愿避免那种在没有什么基础的情况下最终变得相当虔诚的事情（例如，大括号放置），但是示例可能包括诸如“单元测试实际上并没有很大帮助”或“公共领域真的可以”这样的事情。重要的是（无论如何对我而言）是您的观点背后有原因。
请提出您的意见和理由-无论您是否同意，我都会鼓励人们投票支持有争议和有趣的意见。
Answers:
那些不会在业余时间编写代码的程序员将永远不会像那些程序员那样优秀。
我认为，即使最聪明，最有才能的人也永远不会成为真正的优秀程序员，除非他们将其视为一项工作。这意味着他们一边做一些小项目，要么在业余时间就与许多不同的语言和想法混为一谈。
（注意：我并不是说优秀的程序员除了编程之外什么也不做，但是他们比9到5的程序还要多。）
“谷歌搜索”是可以的！
是的，我知道这让某些人感到不快，因为他们多年的沉思和/或光荣的编程书籍正逐渐被任何人都可以在几秒钟内访问的资源所困扰，但是您不应该对他人不利使用它。
我常常听到批评性地对问题进行谷歌搜索，这确实是没有道理的。首先，必须承认每个人都需要参考材料。您一无所知，您将需要查找所有内容。考虑到这一点，从哪里获取信息真的很重要吗？您是在书中查找，在Google上查找还是从幻觉的青蛙那里听到它，这有关系吗？不。正确答案就是正确答案。
重要的是您理解材料，将其用作结束成功编程解决方案的手段，并且客户/您的雇主对结果感到满意。
（尽管如果您从说幻的青蛙那里得到答案，您可能应该同样会得到一些帮助）
实际上，大多数代码注释是代码复制的有害形式。
我们将大部分时间用于维护其他人（或我们自己）编写的代码，而糟糕，错误，过时，误导性的注释必须位于代码中最烦人的工件列表的顶部。
我认为最终很多人都将其清空，尤其是那些花箱怪兽。
最好集中精力使代码具有可读性，必要时进行重构，并尽量减少成语和古怪。
另一方面，许多课程都说注释比代码本身几乎重要得多，导致下一行在invoiceTotal注释样式中增加了一行。
并非所有程序员都是一样的
经理经常认为开发人员A ==开发人员B只是因为他们具有相同的经验水平等等。实际上，一个开发人员的性能可能是另一个开发人员的10倍甚至100倍。
谈论它在政治上是有风险的，但是有时候我想指出一点，即使几个团队成员看起来具有相同的技能，但情况并非总是如此。我什至看到过这样的情况，主要开发人员“超出了希望”，初级开发人员完成了所有实际工作-不过，我确保他们得到了认可。:)
1）商业应用闹剧：
我认为整个“企业”框架都是烟和镜子。J2EE，.NET，大多数Apache框架和大多数用于管理此类事物的抽象所带来的复杂性远超过其解决的复杂性。
采取任何常规的Java或.NET ORM，或采用任何所谓的现代MVC框架，只要它们能“神奇”地解决繁琐而简单的任务即可。您最终要编写大量难以验证和快速编写的难看的XML样板。您拥有大量的API，其中一半仅用于集成其他API的工作，无法回收的接口以及仅用于克服Java和C＃的灵活性的抽象类。我们根本不需要大部分。
具有自己简明的描述符语法的所有不同应用程序服务器，过于复杂的数据库和群件产品又如何呢？
这样做的目的不是复杂性==坏，而是不必要的复杂性==坏。我曾在大型企业安装中工作过，其中某些安装是必需的，但即使在大多数情况下，也需要一些本地编写的脚本和简单的Web前端来解决大多数用例。
我将尝试用简单的Web框架，开源数据库和琐碎的编程结构替换所有这些企业应用程序。
2）所需的n年经验：
除非您需要顾问或技术人员来处理与应用程序，API或框架相关的特定问题，否则您实际上并不需要在该应用程序上具有5年经验的人员。您需要一名能够阅读文档的开发人员/管理员，具有您所从事工作领域的专业知识并且可以快速学习。如果您需要使用某种语言进行开发，那么体面的开发人员将在不到2个月的时间内就将其投入使用。如果您需要X Web服务器的管理员，则他应该在两天内阅读手册页和新闻组，并尽快上手。少花钱，那个人就不值得他得到报酬。
3）常见的“计算机科学”学位课程：
大多数计算机科学和软件工程学位是牛。如果您的第一种编程语言是Java或C＃，则您做错了什么。如果您没有修满几门关于代数和数学的课程，那就错了。如果您不深入研究函数式编程，那是不完整的。如果您不能将循环不变式应用于琐碎的for循环，那么作为一名假定的计算机科学家，您就不值得花些功夫。如果您具有x和y语言以及面向对象的经验，那么它充满了s ***。真正的计算机科学家会从所使用的概念和语法的角度看待一种语言，并将编程方法视为众多方法中的一种，并且对这两种基本哲学都有很好的理解，因此应该选择新的语言，设计方法或规范语言。琐碎的。
Getter和Setters被过度使用
我已经看到数以百万计的人声称公共场所是邪恶的，因此它们将其私有化，并为所有人提供吸气剂和吸气剂。我相信这几乎与公开字段相同，如果使用线程（但通常不是这种情况）或访问器具有业务/表示逻辑（至少有些“奇怪”），则可能会有所不同。
我不赞成公共领域，而是反对为每个人都做一个getter / setter（或Property），然后声称这样做是封装或信息隐藏 ……哈！
更新：
这个答案在其评论中引起了一些争议，因此，我将尝试澄清一下（我会保留原著，因为这是很多人都反对的内容）。
首先：任何使用公共场所的人都应该被判入狱
现在，创建私有字段，然后使用IDE 自动生成getter和setter他们每个人是几乎一样糟糕的利用公共领域。
许多人认为：
private fields + public accessors == encapsulation
我说（自动或不自动）为您的字段生成的getter / setter对实际上与您要实现的所谓封装相反。
最后，让我在这个话题上引用鲍勃叔叔的名字（摘自“清洁代码”的第6章）：
我们将变量保持私有是有原因的。我们不希望任何人依赖他们。我们希望能够一时兴起或一时冲动自由更改其类型或实现方式。那么，为什么有这么多的程序员自动将getter和setter添加到其对象中，从而像公开一样公开其私有字段呢？
UML图被高估了
当然，有有用的图，例如Composite Pattern的类图，但是许多UML图绝对没有价值。
意见：SQL是代码。这样对待
也就是说，就像您的C＃，Java或其他喜欢的对象/过程语言一样，开发一种可读且可维护的格式化样式。
我讨厌看到草率的自由格式SQL代码。如果在页面上同时看到两种样式的花括号时都尖叫，为什么或为什么在看到自由格式的SQL或模糊或混淆JOIN条件的SQL时不尖叫？
如果您是开发人员，则应该能够编写代码
去年，我做了很多采访，在采访的那一部分，我应该测试人们的思维方式，以及他们如何在白板上实现简单到中等的算法。我最初会遇到以下问题：
假设可以使用函数4 *（1-1/3 + 1/5-1/7 + ...）来估计Pi，并且可以提供更多的项以提供更高的精度，请编写一个函数来计算Pi的精度为小数点后5位。
这个问题应该引起您的思考，但对于经验丰富的开发人员来说也不应该望而却步（可以用大约10行C＃回答）。但是，我们的许多候选人（据说是由代理商预先筛选的）甚至都无法开始回答，甚至无法解释他们如何去回答。所以过了一会儿，我开始问一些更简单的问题，例如：
给定圆的面积由Pi乘以半径的平方得到，编写一个函数来计算圆的面积。
令人惊讶的是，超过一半的候选人无法用任何语言编写此功能（我可以阅读大多数流行的语言，因此我可以让他们使用他们选择的任何语言，包括伪代码）。我们有无法使用C＃编写此功能的“ C＃开发人员”。
我对此感到惊讶。我一直认为开发人员应该能够编写代码。如今看来，这是一个有争议的观点。当然，这是面试候选人中！
编辑：
评论中有很多讨论，关于第一个问题是好是坏，以及在面试中您是否应该问像这样复杂的问题。除了要说您在很大程度上遗漏了帖子的要点之外，我不会在这里深入探讨（这是一个全新的问题）。
是的，我说人们不能对此采取任何措施，但是第二个问题是微不足道的，许多人也不能对此采取任何措施！任何自称为开发人员的人都应该能够在几秒钟内写下第二个答案，而无需考虑。许多不能。
设计模式对好的设计的伤害大于对设计的帮助。
IMO软件设计，尤其是优秀的软件设计，千差万别，无法在模式中进行有意义的捕捉，尤其是在人们实际上可以记住的少数模式中，而且它们太抽象了，人们无法真正记住很多。因此，他们没有太大帮助。
另一方面，太多的人迷上了这个概念，并试图将模式应用到任何地方-通常，在生成的代码中，您无法在所有（完全没有意义的）单例和抽象工厂之间找到实际的设计。
更少的代码胜于更多！
如果用户说“就是这样？”，而您的工作仍然不可见，则说明操作正确。荣耀可以在其他地方找到。
单元测试不会帮助您编写好的代码
进行单元测试的唯一原因是要确保已经运行的代码不会中断。首先编写测试，或为测试编写代码是荒谬的。如果在代码之前写测试，您甚至都不知道边缘情况是什么。您可能拥有通过测试的代码，但是在无法预料的情况下仍然失败。
而且，优秀的开发人员将保持较低的凝聚力，这将使添加新代码不太可能引起现有内容的问题。
实际上，我将进一步概括一下，
软件工程中的大多数“最佳实践”都可以防止不良的程序员遭受太大的破坏。
他们在那里帮助不良的开发人员，并防止他们犯下笨拙的错误。当然，由于大多数开发人员都不好，所以这是一件好事，但是好的开发人员应该获得通过。
写小的方法。 程序员似乎喜欢在许多不同的事情上编写loong方法。
我认为应该在任何可以命名的地方创建一种方法。
软件开发只是工作
不要误会我的意思，我非常喜欢软件开发。在过去的几年中，我已经写了一个博客。我在这里花费了足够的时间来获得超过5000点的声望。而且我在一家初创公司工作，通常每周工作60小时，而我的薪水却比承包商少得多，因为团队很棒，工作很有趣。
但是，按照宏伟的计划，这只是一项工作。
它的重要性排在诸如家庭，我的女友，朋友，幸福等许多事物之下，而如果我拥有无限的现金供应（如骑摩托车，帆船或滑雪板），我宁愿做其他事情。
我认为有时候很多开发人员会忘记开发只是让我们生活中更重要的事情（通过做我们喜欢的事情来拥有它们）而不是最终的目标。
软件设计师/设计师被高估了
作为开发人员，我讨厌软件架构师的想法。他们基本上是不再全职编写代码，阅读杂志和文章，然后告诉您如何设计软件的人。只有真正专职从事软件工作的人才能这样做。我不在乎您是否在5年前成为架构师之前是世界上最好的编码器，您的意见对我毫无用处。
那怎么引起争议？
编辑（澄清）：我认为大多数软件架构师都是出色的业务分析师（与客户交谈，编写需求，测试等），我只是认为他们在软件设计，高级或其他方面没有地位。
没有“一刀切”的发展方式
我很惊讶这是一个有争议的观点，因为在我看来，这是常识。但是，流行博客上有很多条目都在倡导“一刀切”的发展方式，所以我认为我实际上可能只是少数。
在没有任何信息被了解之前，我一直认为它是任何项目的正确方法，例如使用测试驱动开发（TDD），域驱动设计（DDD），对象关系映射（ORM） ，敏捷（大写A），面向对象（OO）等，涵盖了从方法论到体系结构再到组件的所有内容。当然，所有这些都有很好的市场缩写。
人们甚至似乎甚至在他们的博客上贴上徽章，例如“ I'm Test Driven”或类似标签，似乎无论项目项目的细节如何，严格遵循单一方法实际上是一件好事。
不是。
选择正确的方法，体系结构和组件等，应该在每个项目的基础上进行，不仅取决于您正在处理的项目的类型及其独特的要求，还取决于大小和能力与您合作的团队。