从StackOverflow来的值得回味的编程观点

很多有意思的话语
服务器君一共花费了147.399 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

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

最初的问题“你最受争议的编程观点是什么?”,由Jon Skeet在2009年1月提出。此人可不是无名小卒,C#社区大名鼎鼎的人物,多年微软MVP,所著《深入理解C#》(英文版C# in Depth)一书是C#领域少数不可不读的名著(老赵就说过C#他只推荐两本,这本和CLR via C#),现在Google英国公司任工程师(还真不知道他在那里干什么)。

那么,这个问题当时都有哪些热门答案呢?顺序是随机的。 

  1. 业余时间不会为了好玩而编程的程序员,永远比不上那些以编程为乐的同学。
  2. 我认为即使是最聪明、最有才华的人,如果只是将编程作为工作,也永远成不了真正优秀的程序员。以编程为乐的人会在业余时也搞些小项目,或者弄弄各种不同的编程语言和编程思想。

  3. 单元测试无助于编写优秀代码。
  4. 编写单元测试的唯一理由仅仅是确保已经能工作的代码不会出问题。先写测试或者按测试来写代码是无比荒谬的。如果在代码之前写测试,你都不知道边界情况是什么。虽然能让代码通过测试,但是在没有预见到的情况时还是会出问题。而且,好的开发人员会尽量降低内聚性,新增代码不可能使已有的出问题。

  5. 唯一能放之四海而皆准的最佳实践,是“用脑子思考”。
  6. 太多人喜欢追逐众多时髦技术,想方设法把各种方法、模式、框架用到不适合的地方。新技术和名人大牛的观点并等于适用于实际情况。

  7. 大多数代码中的注释实际上都是代码重复的恶性表现。
  8. 我们大部分时间是在维护其他人(或者我们自己)写的代码,而糟糕、错误、过时和误导性的注释肯定是代码中最令人纠结的东西之一。很多人最终会将它们干掉。应该把精力放在提高代码的可读性、必要时就重构、少用惯用法和奇技淫巧上。另外,许多教材还在宣扬什么注释甚至比代码还重要,结果导致了大量废话连篇的注释。

  9. 依赖Google没什么错。
  10. 这种言论肯定会让那些学富五车的饱学之士恼火。但是谁都需要查资料不是?正确答案就是正确答案,管它是来自哪本秘籍或者私相传授,还是Google出来的呢?重要的是能真正理解,并给出成功的编程解决方案,让客户和老板满意。

  11. 程序员不是生而平等的。
  12. 经理往往认为程序员A==程序员B,因为他们的年头差不多。实际上,一个开发者的效能可以是另一个的十倍甚至百倍。

  13. 我实在不能理解为什么Java是最适合大学教学的第一门语言。
  14. 首先,我相信第一门编程语言应该重在学习控制流和变量,而不是对象和语法。其次,我认为没有调试C/C++内存泄漏经验的人,根本无法完全理解Java的初衷。而且,自然的发展过程应该是从“我怎样做这事”到“我怎样找到能做这事的库”,而不是倒过来。

  15. 如果你只会一门语言,无论多么精通,仍然不是优秀的程序员。
  16. 有人认为,只要精通了C#、Java或者其他什么你学会的第一门语言,就足够了。我不敢苟同。我学习的每一种新语言,都教了不少编程新知,能够反过来用于工作中。任何人只局限于一种语言,都无法充分发挥自己的潜力。而且缺乏求知欲和探索意愿,都不符合优秀程序员的特质。

  17. 偶尔写写垃圾代码也无妨。
  18. 有时候一些特定任务,快而脏的代码能搞定就行了。模式、ORM、SRP(单一职责原则)啥的算了吧。

  19. print语句是有效的调试方式。
  20. 我认为用 System.out.println 之类的输出语句调试代码挺好。这经常比正式的调试要快,而且可以比较不同运行的输出结果。但是投入生产环境之前一定要删除这些语句,或者将它们放入日志语句中。

  21. 你的工作是要把自己摘出来。
  22. 你写的软件都应该让其他任何开发人员花一点时间就能理解并接手。软件应该设计优雅,代码清晰和一致,格式干净,文档合适,每日构建,有恰当的版本管理。如果你被车撞了、被开了、辞职了,公司应该很快能有人很快替代你。如果不能,那你就太悲剧了。有意思的是,你越这样做,你对公司的价值越大。 

    原帖下面有人评论:你如果无法被替代,也就无法升职啦。

  23. getter和setter被极度滥用了。
  24. 成千上万的人都说公共字段是罪恶的,应该设为私有,提供getter和setter。我觉得其实没啥不同,除非程序是多线程的,或者访问方法中有业务或者展示逻辑(这可够怪的)。我并不是赞成用公共字段,只是反对用访问方法或者属性包一下,就号称封装、信息隐藏了。

  25. SQL也是代码,请等而视之。
  26. SQL和C#, Java或者其他对象、过程语言没什么不同,请注意代码的格式、可读性和可维护性。

  27. UML图被高估了。
  28. 有些图当然是有用的,比如Composite模式的类图。但许多UML图都毫无价值。

    CSDN编者注:记得Robert Martin在《敏捷软件开发(C#版)》里讲UML时,基本上是讲一个图然后说,好像没什么用,我就没怎么用过……同一个问题下面还有一个相关的答案:代码==设计。认为高级语言代码比UML图和文档更有效。

  29. 可读性是代码最重要的方面。
  30. 比正确性还重要。可读的代码也容易修正,容易优化、修改、理解。而且其他开发者也能从中获益。

  31. XML被大大高估了。
  32. 很多随波逐流跳上XML这黑船的人都没过脑子。XML用于Web应用不错,因为它本来就是干这个的。此外的问题定义、设计思路应该尽量不用XML。

  33. 软件开发只是一份工作而已。
  34. 我热爱软件开发, 我现在一家创业公司干,每周公司60小时,而且工资不高,只因为团队很棒,工作很有趣。但站得高一点来看,这仍然只是一份工作而已。它不如家庭、我的女友、其他朋友、幸福等等重要。要是有足够的钱,我宁愿去玩摩托、游艇或单板滑雪。许多开发者忘记了写程序不是最终目的,它只是为我们提供条件,去高高兴兴地做生命中最重要的事情。

    CSDN编者注:这条和第1条好像有点对着来嘛。

  35. 开发人员就应该能够写代码。
  36. 去年做了很多面试,我主要会测人们的思路,如何在白板上实现比较简单的算法。我往往从这样的问题开始:

    已知Pi可以用函数4 * (1 – 1/3 + 1/5 – 1/7 + …) 计算,项越多越精确,请写一个函数,计算小数点后5位的Pi。

    这是一个10行C#就能搞定的问题。但许多面试者甚至毫无思路。所以我只好接着问这样的问题:

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

    居然有超过半数的人无法用任何语言完成这个函数!唉,开发人员应该能够写代码,现在连这个都成有争议的观点了……

  37. 设计模式弊大于利。
  38. 软件设计,尤其是好的软件设计千变万化,没法有意义地用模式去总结,尤其是那些大家记得住的几个模式,而且这些模式也太抽象了,其实没几个人真正记得住太多。所以设计模式其实没啥用。而另一方面呢,又有太多的人为设计模式的概念迷住,想方设法到处用——结果代码中往往除了一些毫无意义的单例和抽象工厂之外,几乎找不到什么设计。

  39. 代码少少益善。
  40. 如果用户看不到你的工作,才是做对了。荣耀在别处。

  41. 性能真的很重要。
  42. 企业应用很滑稽。需要n年经验是胡扯。计算机科学学位课程纯忽悠。
  43. 单元测试无助于编写好代码,软件工程大多数所谓的最佳实践都是为了防范烂程序员搞太多破坏。
  44. 每个程序员都应该熟悉现代计算机的体系结构。
  45. 编写小方法。
  46. PHP真烂!
  47. C++是有史以来最差的语言之一。
  48. 大多数职业程序员都很烂。
  49. 要想成为程序员,你得先学会打字。
  50. 编程之外的各种流程规矩越多,代码质量越差。
  51. 资深的游戏程序员James Hague(名博Prog21是也)也看到此文,觉得这些观点都没啥太大争议性。他专门写了一篇博客,又提出了他自认为更具争议性的观点,其中不少观点指向他之前发表的其他文章:

  52. 计算机科学专业应该只作为辅修学位。
  53. 新程序员还没有弄懂分解问题和将解决方法变成代码之前,就给他们介绍面向对象是大错特错。
  54. 复杂的编译器优化几乎都没什么价值,即使能得到更快的代码。它们会大大降低编译速度而且很可能产生难以处理的bug,使性能问题的处理更加困难。
  55. 不能允许没有十年编程经验的人编写供他人使用的库。忽略此条,抱憾终身。
  56. 代码丑陋与否无关紧要。有没有格式与代码是否工作、可靠没什么关系,可以让自动化工具来整理格式。
  57. 纯函数式编程没啥用。但在命令式代码里杂用一些效果不错。
  58. 软件工程的既定思维反而会阻碍你做出伟大作品。

以上的见解纯粹是个人见解,不一定都对,可以看看,有很多还是挺正确的。

本文地址:http://www.nowamagic.net/librarys/veda/detail/2227,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/2227

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《深入理解MySQL核心技术》 Sasba Pacbev (作者), 李芳 (译者), 于红芸 (译者), 邵健 (译者)

《深入理解MySQL核心技术》:从公共可用性的意义上讲,MySQL源代码是开放源代码,但如果对其不了解,则实质上,它对于您来说是封闭的。MysQL开发团队的前成员Sasha Pachev通过《深入理解MySQL核心技术》给出了MySQL 5的全面指南,揭示了这一强大数据库的内部运作。您将直奔MySQL核心技术,了解各种数据结构和各种方便的功能的运作情况,了解如何添加新的存储引擎和配置选项等。 《深入理解MySQL核心技术》从结构概况讲起,在这一部分解释了MysQL的不同组件是如何协同工作的。接着将学习设置有效的可编译代码副本的步骤,然后使用基本架构添加自己的配置变量和存储引擎。

更多计算机宝库...