20个有争议的编程观点

[广告:最高 ¥2000 红包]阿里云服务器、主机等产品通用,可叠加官网常规优惠使用 | 限时领取
  • 原文:https://programmers.blogoverflow.com/2012/08/20-controversial-programming-opinions/
  • 翻译:码中人
  • 配图:码中人

首先这是程序员问答论坛stackoverflow中“您最有争议的编程观点是什么?” 问题的高分问答的集锦,但这个帖子已经被删除了,也就是说死无对证。

1.  业余时间不以编程为乐的程序员,永远不会像以编程为乐的程序员一样优秀。

我认为即使是最聪明、最有天赋的人也不会成为真正优秀的程序员,除非他们把它当成比工作更重要的事情。也就是说,他们在业余时间做一些小项目,或者只是在业余时间搞很多不同的语言和想法。

作者 rustyshelf


2. 单元测试不会帮助你写出好的代码。

有单元测试的唯一原因是为了确保已经能用的代码不会出错。先写测试,或者先写代码再写测试都很可笑的。如果你先写测试再写代码,你甚至不知道边缘情况是什么。你可能会有通过测试的代码,但在不可预见的情况下仍然失败。而且,好的开发人员会保持较低耦合,这将使新代码的添加不太可能导致现有的东西出现问题。

作者:Chad Okere


3. 你唯一应该一直使用的 “最佳实践 “就是 “开动自己的脑筋”。

太多的人都赶时髦,试图把方法、模式、框架等强加到不值得的事情上。仅仅因为某些东西是新的,或者因为某个受人尊敬的人有一个观点,并不意味着它适合所有的人。

作者:Steven Robbins


4. 大多数代码中的注释其实是一种垃圾代码的重复。

我们花了大部分时间来维护别人(或我们自己)写的代码,而拙劣的、不正确的、过时的、误导性的注释一定是代码中最令人讨厌的人工制品的榜首。我想最终很多人都会把它们忽略掉,尤其是那些花盒怪兽。更好的做法是专注于使代码可读,必要时重构,并尽量减少习语和怪癖。另一方面,许多课程教导说注释几乎比代码本身更重要,导致下一行给 invoiceTotal 增加一个注释的风格。

作者:Ed Guiness


5. “上网查查 “未尝不可!

是的,我知道这触犯了一些人的利益,他们多年紧张的记忆和/或光荣的一摞编程书籍,开始被一个任何人都可以在几秒钟内访问的资源所取代,但你不应该对使用它的人持反对态度。我经常听到google解决问题的答案是批评的结果,这真的是没有意义的。

首先,必须承认,每个人都需要材料来参考。你不是什么都懂,你也需要查资料。承认了这一点,你从哪里得到的资料真的重要吗?你是在书上查的,还是在谷歌上查的,还是从一只会说话的青蛙那里听到的,这重要吗?不,一个正确的答案就是一个正确的答案。重要的是你理解了这些材料,把它作为成功的编程方案的手段,并且客户/你的雇主对结果满意。

作者:PhoenixRedeemer


6. 不是所有的程序员受到合理待遇。

很多时候,管理者认为开发人员A等效于开发人员B,只是因为他们的经验水平相同等等。实际上,一个开发人员的业绩可能是另一个开发人员的10倍甚至100倍。谈论这个问题在政治上是有风险的,但有时我觉得应该指出,即使几个团队成员看起来技术相当,但情况并不总是如此。我甚至看到过这样的情况:主要开发人员 “无可奈何”,而初级开发人员做了所有的实际工作–虽然我相信他们得到了赞美。

作者:Dmitri Nesteruk


7. 我不明白为什么人们认为Java是大学里最好的 “第一 “编程语言。

其一,我认为第一门编程语言应该是这样的,它强调的是学习控制流和变量,而不是对象和语法。其二,我相信没有在C / C++中调试内存泄漏经验的人不能完全理解Java带来的东西。另外,自然的进展应该是从 “我怎么能做这个 “到 “我怎么能找到能做那个的库”,而不是相反。

作者 Learning


8. 如果你只懂一门语言,不管你对它有多精通,你都不是一个伟大的程序员。

似乎有一种态度认为,一旦你真的擅长C#或Java或其他任何你开始学习的语言,那么这就是你所需要的。我不这样认为,因为我所学过的每一门语言都教会了我一些关于编程的新东西,这些知识再反哺工作。我认为,任何一个人如果把自己限制在一门语言上,就永远不会有好的表现。这也向我表明了某种缺乏好奇心和尝试的意愿,这不一定符合我期望在一个真正优秀的程序员身上找到的品质。

作者:glenatron


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

有时候,为了完成一个特定的任务,只需要一段快速而肮脏的垃圾代码。模式,ORM,SRP,不管是什么……在控制台搞一下或简单写个Web应用程序,写一些内联SQL,然后快速地完成需求。

作者:jfar


10. 打印语句是调试代码的有效方法。

我相信,通过使用System.out.println(或任何适合你的语言的打印语句)来调试你的代码是完全可行的。通常情况下,这可以比调试更快,而且你可以将打印的输出与应用程序的其他运行进行比较。只要确保在生产时删除打印语句(或者更好的是,将它们变成日志语句)。

作者:David


11. 你的工作就是让自己失业。

当你为你的雇主编写软件时,你所创建的任何软件都要以这样的方式编写,即它可以被任何开发人员拾起并以最小的努力理解。它设计得很好,写得清晰一致,格式干净,在需要的地方有文档,每天按预期构建,检查到仓库,并有适当的版本。

如果你被公交车撞了,下岗,被解雇,或者走下神坛,你的雇主应该能够在一瞬间通知你替换你,下一个人可以介入你的角色,拿起你的代码,顶多一周内就可以开始运行。如果他或她做不到这一点,那你就太失败了。有趣的是,我发现,有了这个目标,我对雇主来说更有价值。我越是努力成为一次性的人,对他们来说就越有价值。

作者:迈克-霍弗


12. Getters和Setters被过度使用。

我见过数以百万计的人声称公共字段是邪恶的,所以他们将其私有化,并为所有字段提供getter和setter。我相信这与将字段公开几乎是一样的,如果你使用线程(但一般情况下不是这样)或者如果你的访问者有业务/展示逻辑(至少是一些 “奇怪 “的东西),也许会有一点不同。我并不赞成公共字段,但反对为每个字段建立一个getter/setter(或Property),然后声称这样做是封装或信息隐藏……哈哈!我认为,这是不对的。

作者:Pablo Fernandez


13. 别拿SQL不当代码。

也就是说,就像你的C#、Java或其他喜欢的对象/程序语言一样,开发一种可读和可维护的格式化风格。我讨厌看到马虎的自由格式化的SQL代码。如果你在页面上看到两种样式的大括号时都会尖叫,那么当你看到自由格式化的SQL或模糊或混淆JOIN条件的SQL时,你为什么或为什么不尖叫呢?

作者:MustStayAnonymous


14. UML图被高度高估了。

当然有一些有用的图,比如复合模式的类图,但是很多UML图完全没有价值。
当然也有一些有用的图,比如复合模式的类图,但是很多UML图完全没有价值。

作者:Ludwig Wensauer


15. 可读性是最重要的。

可读性甚至比正确性更重要。如果它是可读的,它就很容易修复。也容易优化,容易改变,容易理解。而且希望其他开发者也能从中学到一些东西。

作者:Craig P. Motlin


16. XML被高估了。

我认为有太多的人从未经过思考,就跳上了XML的浪潮……XML用于网络的东西是很好的,因为它是为它设计的。否则,我认为一些问题定义和设计思想应该优先于任何使用它的决定。

作者:Over Rated


17. 软件开发也只是一份工作。

我很喜欢软件开发。在过去的几年里,我写了一个关于这个主题的系列博客。我在这里花了足够多的时间,有超过5000个信誉点。我在一家初创公司工作,每周工作时间通常为60小时,收入比我作为一个承包商要少得多,因为团队很棒,工作也很有趣。

但本质而言,这只是一份工作。它的重要性排在很多事情之下,比如家庭、我的女朋友、朋友、幸福等,如果有无限的现金供应,我肯定选择做的其他事情之下,比如骑摩托车、帆船游艇或者滑雪板。我觉得有时候很多开发者忘记了,开发只是让我们拥有生活中更重要的东西(通过做我们喜欢的事情来拥有),而不是作为最终目标本身。

作者:Greg Beech


18. 如果你是一个开发人员,你应该会写代码。

(这不是废话吗,看完我不太相信)

去年我做了不少面试,我面试的部分应该是测试大家的思维方式,以及如何在白板上实现简单到中等的算法。我一开始的问题是这样的。

考虑到Pi可以用函数4*(1 – 1/3 + 1/5 – 1/7 +… )来估计,更多的项会带来更高的精度,请写一个函数,计算Pi的精度达到小数点后5位。

这是一个应该让你思考的问题,但对于一个经验丰富的开发人员来说,应该不是遥不可及的问题(用大约10行C#语言就可以回答)。然而,我们的许多(据说是经过机构预选的)候选人甚至无法开始回答这个问题,甚至无法解释他们如何去回答这个问题。所以过了一段时间后,我开始问一些比较简单的问题,比如。

假设圆的面积是Pi乘以半径的平方,写一个函数来计算圆的面积。

令人惊讶的是,超过一半的考生不会用任何语言写这个函数(我可以读懂大多数流行的语言,所以我让他们使用任何他们选择的语言,包括伪代码)

我们有 “C#开发人员 “不能用C#写这个函数。我对此感到很惊讶。我一直认为,开发人员应该能够写代码。现在看来,这是个有争议的观点。当然,在面试候选人中也是如此

作者:Greg Beech


19. 设计模式对好设计的伤害大于帮助。

软件设计,尤其是好的软件设计太多变了,无法用模式来有意义地捕捉,尤其是人们能真正记住的模式数量很少–而且这些模式太抽象了,人们真正能记住的不只是少数几个。所以它们没有什么帮助。而另一方面,太多人迷恋这个概念,并试图将模式应用到各个地方–通常,在所产生的代码中,你无法在所有(完全没有意义的)Singletons和Abstract Factories之间找到实际的设计。

作者:Michael Borgwardt


20. 代码越少越好

如果用户说 “就这(么点)?”,没有体现你的工作量,那就是做对了。相信我,你要把这当成对你的最高赞誉。

作者:Jas Panesar


你怎么看?请在文末留言,你最有争议的编程观点是什么?

码中人 微信公众号