那些争议最大的编程观点

　　摘要：那些看似惊人但却值得回味的编程观点……

　　知名问答网站StackOverflow之所以成功，合理的规则与严格执行是重要的原因，所以删帖是经常的。不过有时候执行得过严了，被删的问答不时会有惊艳之作。这不，他们的博客8月29日的文章“20个最受争议的编程观点”说的就是这样一个被删帖。此文一出，立刻在Reddit、Hacker News等各大技术新闻站上引起了热议。

　　实际上2010年酷壳曾经有文章介绍过其中的十条，但观点本身没有翻译。

　　最初的问题“你最受争议的编程观点是什么?”(这里还能看到存档)，由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小时，而且工资不高，只因为团队很棒，工作很有趣。但站得高一点来看，这仍然只是一份工作而已。它不如家庭、我的女友、其他朋友、幸福等等重要。要是有足够的钱，我宁愿去玩摩托、游艇或单板滑雪。许多开发者忘记了写程序不是最终目的，它只是为我们提供条件，去高高兴兴地做生命中最重要的事情。

原文转自：http://www.ltesting.net