首页 编程技术20个争议最大的编程观点,你认可几点?

20个争议最大的编程观点,你认可几点?

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

在StackOverflow上有这样的一个贴子《What’s your most controversial programming opinion?》,中文的意思是“你认为最受争议的编程观点有哪些?”,这个帖子是Jon Skeet在2009年1月提出,Jon Skeet是C#社区大名鼎鼎的人物,多年微软MVP,所著《深入理解C#》(英文版C# in Depth)一书是C#领域少数不可不读的名著,他现任Google英国公司的一名高级工程师。

在这个话题里种共有400多个主回贴,以及上千个子回贴中,我觉得很多观点倒不是有争议的,而是非常正确的,如果一定要说这些有争议,那也只能是对哪些没真正做过开发的人而言的。

下面就和大家一起分享下这些“有争议的”观点,希望对你有所帮助!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. 开发人员就应该能够写代码。

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

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

本文链接:https://www.yunweipai.com/656.html

网友评论comments

回复 hiswing 取消回复

您的电子邮箱地址不会被公开。

  1. Mao说道:

    XML被大大高估了。
    —这个确实,xml的性能一直被诟病,相比于property或cfg文件,要差很多。不到万不得已,请别用xml。

  2. hiswing说道:

    第19,不认同,设计模式不是让你死搬硬套,死记硬背。模式的意义在于总结应用功能的共同特性,以较为适当的程序结构去实现。比如NIO的设计就是设计模式应用很好的例子。

  3. Wang说道:

    6. 程序员不是生而平等的。

    可惜给我发工资的人认为每个人都差不多。

Copyright © 2012-2022 YUNWEIPAI.COM - 运维派 京ICP备16064699号-6
扫二维码
扫二维码
返回顶部