那些争议最大的编程观点
jopen 12年前
<p> 作者：刘江@CSDN </p> <p> 知名问答网站 <a href="/misc/goto?guid=4958188962313964239" rel="nofollow" target="_blank">StackOverflow</a> 之所以成功，合理的规则与严格执行是重要的原因，所以删帖是经常的。不过有时候执行得过严了，被删的问答不时会有惊艳之作。这不，他们的博客 8 月 29 日的文章<a href="/misc/goto?guid=4958523244060685416" rel="nofollow" target="_blank">“20个最受争议的编程观点”</a>说的就是这样一个被删帖。此文一出，立刻在 <a href="/misc/goto?guid=4958523244164245795" rel="nofollow" target="_blank">Reddit/Programming</a>、<a href="/misc/goto?guid=4958523244255349916" rel="nofollow" target="_blank">Hacker News</a> 等各大技术新闻站上引起了热议。</p> <p> 实际上陈皓曾经翻译<a href="/misc/goto?guid=4958523244357187714" target="_blank">介绍过其中的十条</a>，但观点本身没有翻译。</p> <p> 最初的问题“你最受争议的编程观点是什么？”（<a href="/misc/goto?guid=4958339824583747680" rel="nofollow" target="_blank">这里</a>还能看到存档），由 Jon Skeet 在 2009 年 1 月提出。此人可不是无名小卒，C#社区大名鼎鼎的人物，多年微软 MVP，所著《<a href="http://www.amazon.cn/gp/product/B006OI9JUE/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=536&creative=3200&creativeASIN=B006OI9JUE&linkCode=as2&tag=vastwork-23" rel="nofollow" target="_blank">深入理解C#</a>》（英文版<em>C# in Depth</em>）一书是 C# 领域少数不可不读的名著（<a href="/misc/goto?guid=4958523244577847992" rel="nofollow" target="_blank">老赵就说过</a>C#他只推荐两本，这本和<em>CLR via C#</em>），现在 Google 英国公司任工程师（还真不知道他在那里干什么）。</p> <p> 那么，这个问题当时都有哪些热门答案呢？顺序是随机的。</p> <p> <strong>1、业余时间不会为了好玩而编程的<a title="程序员的本质" href="/misc/goto?guid=4958202204547787659">程序员</a>，永远比不上那些以编程为乐的同学。</strong></p> <p> 我认为即使是最聪明、最有才华的人，如果只是将编程作为工作，也永远成不了真正优秀的程序员。以编程为乐的人会在业余时也搞些小项目，或者弄弄各种不同的编程语言和编程思想。</p> <p> <strong>2、单元测试无助于编写优秀代码。</strong></p> <p> 编写单元测试的唯一理由仅仅是确保已经能工作的代码不会出问题。先写测试或者按测试来写代码是无比荒谬的。如果在代码之前写测试，你都不知道边界情况是什么。虽然能让代码通过测试，但是在没有预见到的情况时还是会出问题。而且，好的开发人员会尽量降低内聚性，新增代码不可能使已有的出问题。</p> <p> <strong>3、唯一能放之四海而皆准的最佳实践，是“用脑子思考”。</strong></p> <p> 太多人喜欢追逐众多时髦技术，想方设法把各种方法、模式、框架用到不适合的地方。新技术和名人大牛的观点并等于适用于实际情况。</p> <p> <strong>4、大多数代码中的注释实际上都是代码重复的恶性表现。</strong></p> <p> 我们大部分时间是在维护其他人（或者我们自己）写的代码，而糟糕、错误、过时和误导性的注释肯定是代码中最令人纠结的东西之一。很多人最终会将它们干掉。应该把精力放在提高代码的可读性、必要时就<a title="重构" href="http://www.amazon.cn/gp/product/B003BY6PLK/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=vastwork-23&linkCode=as2&camp=536&creative=3200&creativeASIN=B003BY6PLK" rel="nofollow" target="_blank">重构</a>、少用惯用法和奇技淫巧上。另外，许多教材还在宣扬什么注释甚至比代码还重要，结果导致了大量废话连篇的注释。</p> <p> <strong>5、依赖 Google 没什么错。</strong></p> <p> 这种言论肯定会让那些学富五车的饱学之士恼火。但是谁都需要查资料不是？正确答案就是正确答案，管它是来自哪本秘籍或者私相传授，还是 Google 出来的呢？重要的是能真正理解，并给出成功的编程解决方案，让客户和老板满意。</p> <p> <strong>6、程序员不是生而平等的。</strong></p> <p> 经理往往认为程序员A==程序员B，因为他们的年头差不多。实际上，一个开发者的效能可以是另一个的十倍甚至百倍。</p> <p> <strong>7、我实在不能理解为什么 Java 是最适合大学教学的第一门语言。</strong></p> <p> 首先，我相信第一门编程语言应该重在学习控制流和变量，而不是对象和语法。其次，我认为没有调试C/C++内存泄漏经验的人，根本无法完全理解 Java 的初衷。而且，自然的发展过程应该是从“我怎样做这事”到“我怎样找到能做这事的库”，而不是倒过来。</p> <p> <strong>8、如果你只会一门语言，无论多么精通，仍然不是优秀的程序员。</strong></p> <p> 有人认为，只要精通了C#、Java 或者其他什么你学会的第一门语言，就足够了。我不敢苟同。我学习的每一种新语言，都教了不少编程新知，能够反过来用于工作中。任何人只局限于一种语言，都无法充分发挥自己的潜力。而且缺乏求知欲和探索意愿，都不符合优秀程序员的特质。</p> <p> <strong>9、偶尔写写垃圾代码也无妨。</strong></p> <p> 有时候一些特定任务，快而脏的代码能搞定就行了。模式、ORM、SRP（单一职责原则）啥的算了吧。</p> <p> <strong>10、print 语句是合法的调试方式。</strong></p> <p> 我认为用 System.out.println 之类的输出语句调试代码挺好。这经常比正式的调试要快，而且可以比较不同运行的输出结果。但是投入生产环境之前一定要删除这些语句，或者将它们放入日志语句中。</p> <p> <strong>11、你的工作是要把自己摘出来。</strong></p> <p> 你写的软件都应该让其他任何开发人员花一点时间就能理解并接手。软件应该设计优雅，代码清晰和一致，格式干净，文档合适，每日构建，有恰当的版本管理。如果你被车撞了、被开了、辞职了，公司应该很快能有人很快替代你。如果不能，那你就太悲剧了。有意思的是，你越这样做，你对公司的价值越大。</p> <p> 原帖下面有人评论：你如果无法被替代，也就无法升职啦。</p> <p> <strong>12、getter 和 setter 被极度滥用了。</strong></p> <p> 成千上万的人都说公共字段是罪恶的，应该设为私有，提供 getter 和 setter。我觉得其实没啥不同，除非程序是多线程的，或者访问方法中有业务或者展示逻辑（这可够怪的）。我并不是赞成用公共字段，只是反对用访问方法或者属性包一下，就号称封装、信息隐藏了。</p> <p> <strong>13、SQL 也是代码，请等而视之。</strong></p> <p> SQL 和C#， Java 或者其他对象、过程语言没什么不同，请注意代码的格式、可读性和可维护性。</p> <p> <strong>14、UML 图被高估了</strong>。</p> <p> 有些图当然是有用的，比如 Composite 模式的类图。但许多 UML 图都毫无价值。</p> <p> CSDN 编者注：记得 Robert Martin 在《<a title="敏捷软件开发(原则模式与实践) " href="http://www.amazon.cn/gp/product/B00116MMA8/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&camp=536&creative=3200&creativeASIN=B00116MMA8&linkCode=as2&tag=vastwork-23" rel="nofollow" target="_blank">敏捷软件开发</a>（C#版）》里讲 UML 时，基本上是讲一个图然后说，好像没什么用，我就没怎么用过……同一个问题下面还有一个相关的答案：代码==设计。认为高级语言代码比 UML 图和文档更有效。</p> <p> <strong>15、可读性是代码最重要的方面。</strong></p> <p> 比正确性还重要。可读的代码也容易修正，容易优化、修改、理解。而且其他开发者也能从中获益。</p> <p> <strong>16、XML 被大大高估了。</strong></p> <p> 很多随波逐流跳上 XML 这黑船的人都没过脑子。XML 用于 Web 应用不错，因为它本来就是干这个的。此外的问题定义、设计思路应该尽量不用 XML。</p> <p> <strong>17、软件开发只是一份工作而已。</strong></p> <p> 我热爱软件开发， 我现在一家创业公司干，每周公司 60 小时，而且工资不高，只因为团队很棒，工作很有趣。但站得高一点来看，这仍然只是一份工作而已。它不如家庭、我的女友、其他朋友、幸福等等重要。要是有足够的钱，我宁愿去玩摩托、游艇或单板滑雪。许多开发者忘记了写程序不是最终目的，它只是为我们提供条件，去高高兴兴地做生命中最重要的事情。</p> <p> CSDN 编者注：这条和第 1 条好像有点对着来嘛。</p> <p> <strong>18、开发人员就应该能够写代码。</strong></p> <p> 去年做了很多面试，我主要会测人们的思路，如何在白板上实现比较简单的算法。我往往从这样的问题开始：</p> <p> 已知 Pi 可以用函数 4 * (1 – 1/3 + 1/5 – 1/7 + …) 计算，项越多越精确，请写一个函数，计算小数点后 5 位的 Pi。</p> <p> 这是一个 10 行 C# 就能搞定的问题。但许多面试者甚至毫无思路。所以我只好接着问这样的问题：</p> <p> 已知圆的面积是 Pi 乘以半径的平方，写一个函数计算。</p> <p> 居然有超过半数的人无法用任何语言完成这个函数！唉，开发人员应该能够写代码，现在连这个都成有争议的观点了……</p> <p> <strong>19、<a title="设计模式:可复用面向对象软件的基础" href="http://www.amazon.cn/gp/product/B001130JN8/ref=as_li_qf_sp_asin_il_tl?ie=UTF8&tag=vastwork-23&linkCode=as2&camp=536&creative=3200&creativeASIN=B001130JN8" rel="nofollow" target="_blank">设计模式</a>弊大于利。</strong></p> <p> 软件设计，尤其是好的软件设计千变万化，没法有意义地用模式去总结，尤其是那些大家记得住的几个模式，而且这些模式也太抽象了，其实没几个人真正记得住太多。所以设计模式其实没啥用。而另一方面呢，又有太多的人为设计模式的概念迷住，想方设法到处用——结果代码中往往除了一些毫无意义的单例和抽象工厂之外，几乎找不到什么设计。</p> <p> <strong>20、代码少少益善。</strong></p> <p> 如果用户看不到你的工作，才是做对了。荣耀在别处。</p> <p> 其他比较热门的答案还有：</p> <p> <strong>21. 性能真的很重要。</strong></p> <p> <strong>22. 企业应用很滑稽。需要n年经验是胡扯。计算机科学学位课程纯忽悠。</strong>（<a href="/misc/goto?guid=4958523244953542655" rel="nofollow" target="_blank">链接</a>）</p> <p> <strong>23. </strong><strong>单元测试无助于编写好代码，软件工程大多数所谓的最佳实践都是为了防范烂程序员搞太多破坏。</strong>（<a href="/misc/goto?guid=4958523245082890832" rel="nofollow" target="_blank">链接</a>）</p> <p> <strong>24. 每个程序员都应该熟悉现代计算机的体系结构。</strong></p> <p> <strong>25. 编写小方法。</strong></p> <p> <strong>26. PHP 真烂！</strong></p> <p> <strong>27. C++ 是有史以来最差的语言之一。</strong>（<a href="/misc/goto?guid=4958523245205050686" rel="nofollow" target="_blank">链接</a>）</p> <p> <strong>28. 大多数职业程序员都很烂。</strong></p> <p> <strong>29. 要想成为程序员，你得先学会打字。</strong></p> <p> <strong>30. 编程之外的各种流程规矩越多，代码质量越差。</strong>（<a href="/misc/goto?guid=4958523245323796824" rel="nofollow" target="_blank">链接</a>）</p> <p> 资深的游戏程序员 James Hague（名博 <a href="/misc/goto?guid=4958523245456342615" rel="nofollow" target="_blank">Prog21</a>是也）也看到此文，觉得这些观点都没啥太大争议性。他专门写了一篇博客，又提出了他自认为更具争议性的观点，其中不少观点指向他之前发表的其他文章：</p> <p> <strong>31. 计算机科学专业应该只作为辅修学位。</strong></p> <p> <strong>32. 新程序员还没有弄懂分解问题和将解决方法变成代码之前，就<a href="/misc/goto?guid=4958523245574396546" rel="nofollow" target="_blank">给他们介绍面向对象</a>是大错特错。</strong></p> <p> <strong>33. 复杂的编译器优化几乎都没什么价值，即使能得到更快的代码。它们会<a href="/misc/goto?guid=4958523245707185208" rel="nofollow" target="_blank">大大降低编译速度</a>而且很可能产生难以处理的 bug，使<a href="/misc/goto?guid=4958523245836770502" rel="nofollow" target="_blank">性能问题的处理</a>更加困难。</strong></p> <p> <strong>34. </strong><strong>不能允许</strong><strong>没有十年编程经验的人编写供他人使用的库。忽略此条，抱憾终身。</strong></p> <p> <strong>35. <a href="/misc/goto?guid=4958523245953088638" rel="nofollow" target="_blank">代码丑陋与否无关紧要</a>。有没有格式与代码是否工作、可靠没什么关系，可以让自动化工具来整理格式。</strong></p> <p> <strong>36. <a href="/misc/goto?guid=4958523246079341056" rel="nofollow" target="_blank">纯函数式编程没啥用</a>。但在命令式代码里杂用一些效果不错。</strong></p> <p> <strong>37. 软件工程的既定思维反而会<a href="/misc/goto?guid=4958523246200726562" rel="nofollow" target="_blank">阻碍你做出伟大作品</a>。</strong></p> <p> 对这些编程观点你怎么看？你有什么值得争议的惊人之语吗，欢迎晒出来大家共赏析。</p> <div id="come_from"> 来自: <a id="link_source2" href="/misc/goto?guid=4958523246321653383" target="_blank">CSDN</a> </div>