知名问答网站StackOverflow之因此成功，合理的规则与严格执行是重要的缘由，因此删帖是常常的。不过有时候执行得过严了，被删的问答不时会有惊艳之做。这不，他们的博客8月29日的文章“20个最受争议的编程观点”说的就是这样一个被删帖。此文一出，马上在Reddit、Hacker News等各大技术新闻站上引发了热议。面试
最初的问题“你最受争议的编程观点是什么？”，由Jon Skeet在2009年1月提出。此人可不是无名小卒，C#社区大名鼎鼎的人物，多年微软MVP，所著《深刻理解C#》（英文版C# in Depth）一书是C#领域少数不可不读的名著（老赵就说过C#他只推荐两本，这本和CLR via C#），如今Google英国公司任工程师（还真不知道他在那里干什么）。算法
那么，这个问题当时都有哪些热门答案呢？顺序是随机的。 数据库
- 业余时间不会为了好玩而编程的程序员，永远比不上那些以编程为乐的同窗。
我认为即便是最聪明、最有才华的人，若是只是将编程做为工做，也永远成不了真正优秀的程序员。以编程为乐的人会在业余时也搞些小项目，或者弄弄各类不一样的编程语言和编程思想。编程
- 单元测试无助于编写优秀代码。
编写单元测试的惟一理由仅仅是确保已经能工做的代码不会出问题。先写测试或者按测试来写代码是无比荒谬的。若是在代码以前写测试，你都不知道边界状况是什么。虽然能让代码经过测试，可是在没有预见到的状况时仍是会出问题。并且，好的开发人员会尽可能下降内聚性，新增代码不可能使已有的出问题。设计模式
- 惟一能放之四海而皆准的最佳实践，是“用脑子思考”。
太多人喜欢追逐众多时髦技术，千方百计把各类方法、模式、框架用到不适合的地方。新技术和名人大牛的观点并等于适用于实际状况。服务器
- 大多数代码中的注释实际上都是代码重复的恶性表现。
咱们大部分时间是在维护其余人（或者咱们本身）写的代码，而糟糕、错误、过期和误导性的注释确定是代码中最使人纠结的东西之一。不少人最终会将它们干掉。应该把精力放在提升代码的可读性、必要时就重构、少用惯用法和奇技淫巧上。另外，许多教材还在宣扬什么注释甚至比代码还重要，结果致使了大量废话连篇的注释。多线程
- 依赖Google没什么错。
这种言论确定会让那些学富五车的饱学之士恼火。可是谁都须要查资料不是？正确答案就是正确答案，管它是来自哪本秘籍或者私相传授，仍是Google出来的呢？重要的是能真正理解，并给出成功的编程解决方案，让客户和老板满意。框架
- 程序员不是生而平等的。
经理每每认为程序员A==程序员B，由于他们的年头差很少。实际上，一个开发者的效能能够是另外一个的十倍甚至百倍。编程语言
- 我实在不能理解为何Java是最适合大学教学的第一门语言。
首先，我相信第一门编程语言应该重在学习控制流和变量，而不是对象和语法。其次，我认为没有调试C/C++内存泄漏经验的人，根本没法彻底理解Java的初衷。并且，天然的发展过程应该是从“我怎样作这事”到“我怎样找到能作这事的库”，而不是倒过来。
- 若是你只会一门语言，不管多么精通，仍然不是优秀的程序员。
有人认为，只要精通了C#、Java或者其余什么你学会的第一门语言，就足够了。我不敢苟同。我学习的每一种新语言，都教了很多编程新知，可以反过来用于工做中。任何人只局限于一种语言，都没法充分发挥本身的潜力。并且缺少求知欲和探索意愿，都不符合优秀程序员的特质。
- 偶尔写写垃圾代码也无妨。
有时候一些特定任务，快而脏的代码能搞定就好了。模式、ORM、SRP（单一职责原则）啥的算了吧。
- print语句是有效的调试方式。
我认为用 System.out.println 之类的输出语句调试代码挺好。这常常比正式的调试要快，并且能够比较不一样运行的输出结果。可是投入生产环境以前必定要删除这些语句，或者将它们放入日志语句中。
- 你的工做是要把本身摘出来。
你写的软件都应该让其余任何开发人员花一点时间就能理解并接手。软件应该设计优雅，代码清晰和一致，格式干净，文档合适，每日构建，有恰当的版本管理。若是你被车撞了、被开了、辞职了，公司应该很快能有人很快替代你。若是不能，那你就太悲剧了。有意思的是，你越这样作，你对公司的价值越大。
原帖下面有人评论：你若是没法被替代，也就没法升职啦。
- getter和setter被极度滥用了。
成千上万的人都说公共字段是罪恶的，应该设为私有，提供getter和setter。我以为其实没啥不一样，除非程序是多线程的，或者访问方法中有业务或者展现逻辑（这可够怪的）。我并非同意用公共字段，只是反对用访问方法或者属性包一下，就号称封装、信息隐藏了。
- SQL也是代码，请等而视之。
SQL和C#, Java或者其余对象、过程语言没什么不一样，请注意代码的格式、可读性和可维护性。
- UML图被高估了。
有些图固然是有用的，好比Composite模式的类图。但许多UML图都毫无价值。
CSDN编者注：记得Robert Martin在《敏捷软件开发（C#版）》里讲UML时，基本上是讲一个图而后说，好像没什么用，我就没怎么用过……同一个问题下面还有一个相关的答案：代码==设计。认为高级语言代码比UML图和文档更有效。
- 可读性是代码最重要的方面。
比正确性还重要。可读的代码也容易修正，容易优化、修改、理解。并且其余开发者也能从中获益。
- XML被大大高估了。
不少随波逐流跳上XML这黑船的人都没过脑子。XML用于Web应用不错，由于它原本就是干这个的。此外的问题定义、设计思路应该尽可能不用XML。
- 软件开发只是一份工做而已。
我热爱软件开发， 我如今一家创业公司干，每周公司60小时，并且工资不高，只由于团队很棒，工做颇有趣。但站得高一点来看，这仍然只是一份工做而已。它不如家庭、个人女朋友、其余朋友、幸福等等重要。要是有足够的钱，我宁愿去玩摩托、游艇或单板滑雪。许多开发者忘记了写程序不是最终目的，它只是为咱们提供条件，去高高兴兴地作生命中最重要的事情。
CSDN编者注：这条和第1条好像有点对着来嘛。
- 开发人员就应该可以写代码。
去年作了不少面试，我主要会测人们的思路，如何在白板上实现比较简单的算法。我每每从这样的问题开始：
已知Pi能够用函数4 * (1 – 1/3 + 1/5 – 1/7 + …) 计算，项越多越精确，请写一个函数，计算小数点后5位的Pi。
这是一个10行C#就能搞定的问题。但许多面试者甚至毫无思路。因此我只好接着问这样的问题：
已知圆的面积是Pi乘以半径的平方，写一个函数计算。
竟然有超过半数的人没法用任何语言完成这个函数！唉，开发人员应该可以写代码，如今连这个都成有争议的观点了……
- 设计模式弊大于利。
软件设计，尤为是好的软件设计变幻无穷，无法有意义地用模式去总结，尤为是那些你们记得住的几个模式，并且这些模式也太抽象了，其实没几我的真正记得住太多。因此设计模式其实没啥用。而另外一方面呢，又有太多的人为设计模式的概念迷住，千方百计处处用——结果代码中每每除了一些毫无心义的单例和抽象工厂以外，几乎找不到什么设计。
- 代码少少益善。
若是用户看不到你的工做，才是作对了。荣耀在别处。
- 性能真的很重要。
- 企业应用很滑稽。须要n年经验是胡扯。计算机科学学位课程纯忽悠。
- 单元测试无助于编写好代码，软件工程大多数所谓的最佳实践都是为了防范烂程序员搞太多破坏。
- 每一个程序员都应该熟悉现代计算机的体系结构。
- 编写小方法。
- PHP真烂！
- C++是有史以来最差的语言之一。
- 大多数职业程序员都很烂。
- 要想成为程序员，你得先学会打字。
- 编程以外的各类流程规矩越多，代码质量越差。
资深的游戏程序员James Hague（名博Prog21是也）也看到此文，以为这些观点都没啥太大争议性。他专门写了一篇博客，又提出了他自认为更具争议性的观点，其中很多观点指向他以前发表的其余文章：
- 计算机科学专业应该只做为辅修学位。
- 新程序员尚未弄懂分解问题和将解决方法变成代码以前，就给他们介绍面向对象是大错特错。
- 复杂的编译器优化几乎都没什么价值，即便能获得更快的代码。它们会大大下降编译速度并且极可能产生难以处理的bug，使性能问题的处理更加困难。
- 不能容许没有十年编程经验的人编写供他人使用的库。忽略此条，抱憾终身。
- 代码丑陋与否可有可无。有没有格式与代码是否工做、可靠没什么关系，可让自动化工具来整理格式。
- 纯函数式编程没啥用。但在命令式代码里杂用一些效果不错。
- 软件工程的既定思惟反而会阻碍你作出伟大做品。