创建这个博客(blogoverflow)的其中一个初衷是在我们网站(StackOverflow)的古早阶段，网站还未受到那么多的限制，有一些像宝石一般美好的问题虽然被删帖，但仍然值得去记录。即使它们已经不适用于程序员领域，但却不能否认，它们曾经风靡过社区。

我选中的第一个被删除的问题是 Jon Skeet 提出的 “你认为最有争议的编程观点是什么？”（只有 10K 的用户看过这个问题，为此感到抱歉），自 2009 年 2 月 2 号被提出以来，有 391+ 的回答。下文将列出前 20 高赞回答，不分顺序。

1.业余时间不编程的程序员，永远比不上在业余时间编程的程序员

我认为即使是最聪明以及最有天赋的程序员，如果只把编程当作工作，那他/她将永远无法成为一个好的程序员。不只将编程当作工作是指他们会在业余时间另外做一些小项目或捣鼓一些不同的语言和想法。

– rustyshelf.

2.单元测试不会帮你写好代码

单元测试存在的唯一原因是确保已经良好运行的代码不会崩。先写测试或者为测试去编写代码有些可笑，如果你这样做了，你甚至不知道什么是边界测试用例。你还是会写出那些虽然测试通过，但在未预料的场景下失败的代码。此外，一个好的开发者将保持代码低聚合，这样新的代码不太可能引发老代码问题。

– Chad Okere

3.随时都需要用上的唯一“最佳实践”是“动动你的小脑筋”

有太多人跳起来追逐流行，还强制将一些方法、模式、框架等用在不适合它们的地方。或因为新，或因为一些权威人士的观点，但这些理由都无法证明它适合所有人。
– Steven Robbins

4.事实上大多数代码注释都是有害的代码重复

平时我们会花费大多数时间去维护自己或别人写的代码，那些差的、错误的、过时的、容易让人误解的注释绝对能登上最招人烦的人为因素榜单第一名。我想大多数人最后都会把它们删个精光，特别是那些花箱怪物[译者猜测是值外面好看，但里面可怕的东西]。比起这些，把心思花在代码可读性，必要时重构以及减少语义不明的习惯用语更好。另一方面，许多课程都说注释几乎比代码本身更重要，导致代码上一行是订单流水样式的代码注释。

– Ed Guiness

5.“谷歌一下” 是可以的！

是的。我知道这个观点冒犯了一些人，他们多年来的思考和/或引以为荣的编程书正在开始沦落为所有人在几秒钟内触手可得的资源，但也不应该反对那些使用搜索引擎的人。我听过太多针对谷歌问题答案的批评，其实是不讲道理。首先，参考资料是所有人都需要都。你什么都不知道所以你需要去查资料。考虑到这些，从哪里获得信息真的有那么重要吗？从书里面获取，还是从谷歌搜索，甚至是幻觉里的青蛙告诉你信息，有什么关系呢？不重要，正确答案就是正确答案。重要的是你理解这些材料，将它应用于优秀的解决方案，得到客户以及雇主的认可。

– PhoenixRedeemer

6.所有程序员的产出并不相等

项目经理经常认为因为开发者 A 和开发者 B 有着相同的经验水平，所以他们相等。事实上，两个开发者之间的差距可能有 10 倍甚至 100 倍。讨论这个有政治风险，但是有时候我还是想说虽然团队里的几个成员看起来技能水平相当，实际上可能不像看起来那样。我曾经看过技术领导“没救了”，初级开发者完成了所有实际工作——我敢保证他们共享了夸奖。

7.我无法理解为什么大家认为 Java 绝对是大学课程入门必学“第一”语言

首先，我相信第一门编程语言应该强调学习流程控制和变量的必要性，而不是对象或语法。其次，我相信那些没有尝试过调试 C/C++ 内存泄漏问题的人不会理解 Java 带来的好处。学习的自然发展过程应该是从“我应该怎么实现它”到“我怎么找到实现它的库（library）”，而不是反过来。

– Dmitri Nesteruk

8.如果你只懂一种语言，无论你掌握得多好，你都不是一个好的程序员

这个似乎在表明一种你只精通一门语言像 C#或 Java 或者任何一门你开始学习的语言就足够了。我不相信这种理论，每种语言都能教我新的内容，让我可以将它们和其他语言融汇应用到工作中。我认为那些将自己局限在一种语言的人本来可以做得更好。这也向我表明他们缺乏探究性和试验性精神——我期望在一个真正好的程序员身上发现的特质。

– glenatron

9.偶尔写一下垃圾代码是可以的

有时候只需要一些虽快但有污染的垃圾代码就可以完成特定的任务。使用模式、ORMs(Object Relational Mapping)、SPR 等等快速构建控制台/应用或者写一些内联 SQL 代码（感觉不错）也许会超出预期。

– jfar

10.输出打印是一种调试代码的好方法

我觉得使用 System.out.println (或者任何其他语言的输出语句)是一种非常好的调试代码方法。它通常比打断点更快，而且你还可以比较不同运行时的输出数据。只要确保上线时删掉打印代码（或者用日志记录它们会更好）。

– David

11.你工作是为了让自己失去工作

如果你的软件是给雇主写的，代码必须能方便其他开发者接手且便于理解。代码通过精心设计后逻辑清晰且保持一致,它格式整齐,它该有的文档都有,它每日构建后 push 进代码仓库,它保持良好的版本管理。如果你被公交车撞了，被炒鱿鱼，被解雇或者离职，你的雇主随时都能找人代替你。下一个人很快就能捡起你的代码，并在一周之内运行。如果他/她做不到这点，那你就输的离谱。有趣的是，我发现使自己失去工作使我对雇主更有价值。我越努力成为随时抛产品，我对雇主的价值就越高。

– Mike Hofer

12.滥用 Getters 和 Setters

我已经看过千万人声称 public 字段是邪恶的，所以他们 private 所有字段以及给它们提供 getters 和 setters 方法。我坚信这个和全部使用 public 没有太大区别，除非你使用线程（不常见）或者你的 accessors 有一些业务/潜在的逻辑（至少有些“奇怪”）可能有那么一点区别。我不喜欢 public 字段，但是也反对给所有字段加 getter/setter（或 Property）方法，然后声称这是封装或者隐藏信息…哈哈哈！

– Pablo Fernandez

13.像对待代码一样对待 SQL

这指的是 C#、Java 或者任何其他你喜欢的 对象/过程语言都需要渐渐形成一种可读和可维护的格式规范。我讨厌看到潦草自由的 SQL 代码。如果你会为界面上两个格式不统一的尖括号鬼叫，你为什么在看到自由格式、潦草、令人费解的组合条件 SQL 代码不鬼叫？

– MustStayAnonymous

14.高估 UML

当然，有一些有用的图表，例如复合模式的类图，但是许多 UML 图绝对没有价值。

– Ludwig Wensauer

15.代码的可读性是最重要的

可读性甚至比正确性更重要，如果代码可读，就很容易被修复。同时优化、改动、理解代码也简单。希望其他开发人员也可以从代码中学习到些什么。

– Craig P. Motlin

16.XML 被高估了

我想太多人想都没想就跳进了 XML 的浪潮…XML 在 Web 表现不错，因为它就是为 Web 设计的。所以我认为在用它之前，应优先考虑一些定义问题和设计思想。

– Over Rated

17.软件开发只是一个工作

我非常享受软件开发，过去几年我都在写关于这个主题的博客。我花了足够的时间，也得到了大于 5000 的点赞。我在一个初创公司工作，典型地工作 60 个小时，虽然钱比我做外包少，但是团队很棒，工作有趣。但是在生命的宏伟蓝图中，它只是一个工作。它比很多事情都排名低，例如家庭、我的女朋友、朋友、幸福等等。如果我有花不完的钱，我还有很多其他事情去做，例如骑摩托、玩帆船、滑雪。我觉得很多开发者有时候会忘了，程序开发允许我们拥有生命中更重要的事情（拥有它们通过我们享受的方式），而不是成为自己终极目标。

– Greg Beech

18.开发就应该能写代码

去年我面试了很多人，其中一个环节是测试面试者的思维方式，通过在白板上写下简单-中等算法。最开始我会问一些问题例如：
已知 4 * (1 – 1/3 + 1/5 – 1/7 + …) 可以估计 Pi 值，请添加代码让 Pi 值更精确，要求精确到五位小数。
这的确是个需要思考的问题，但是经验丰富的程序员不应该掌控不了它（大概 10 行 C# 代码可以得到答案）。但是，我们许多面试者（猎头公司筛选的）都答不上来，甚至无法解释如何做能找到答案。所以在此之后我开始问他们更简单的问题如：已知圆的面积由 Pi 乘以半径的平方得到，编写一个函数来计算圆的面积。。
结果简直令人叹为观止，超过一半的面试者无法用任一语言写出这个函数（大多数流行语言我都看得懂，所以我允许他们自由选择语言，包括伪代码）。我们有“C# 开发人员”不会用 C# 实现这个函数。这太出乎我的意料了，我一直都觉得开发人员应该会写代码。如今看来是个有争议的观点。这争议当然是存在于面试中的候选人之中。

– Greg Beech

19.设计模式对优秀设计的伤害大于帮助

软件设计，尤其是优秀的软件设计差别很大，这导致无法在模式中提取有意义的内容。特别是我们真正认识的少数模式——它们太抽象以至于我们真正记住的东西很少，因此他们其实没有太大帮助。

另一方面，太多的人沉迷于于概念，想要把模式应用到任何地方。你通常无法在代码中找到所有（完全没有意义的）单例和抽象工厂之间实际的设计。

– Greg Beech

20.代码少总比多好！

如果用户说“就这？”，且你的工作对他来说不可见，这说明你正在做正确的事情。荣耀自有去路，只是不在此处。

– Jas Panesar

译者随笔

拖拖拉拉的翻译了一个月，涂涂改改了几次。

原文在 2012 年发布，2021 年的今天看，好多观点我竟觉得并没有争议，例如偶尔写一下垃圾代码是可以的（哈哈哈哈）。因为现在已经找不到原问题的讨论了，所以在看文章的时候，我只能自己思考为什么不能偶尔写一下垃圾代码，有什么坏处？降低代码品质，后续造成不必要的维护成本…