JavaScript权威Douglas Crockford:代码阅读和每个人都该学的编程

作者:Peter Seibel

关于JavaScript

Seibel:在程序学习之路上有哪些令你后悔的事情?

Crockford:我了解一些语言,但却一直没有机会使用。我花了不少时间学习APL并了解到其衰败的原因,但这门语言真的非常优雅,可我却没有花时间使用它,这太遗憾了。除此以外,我还了解其他一些语言,知道能用它们做什么,但实际上却并没有机会用这些语言思考。

Seibel:我听说你喜欢ES3版本JavaScript的简洁性。

Crockford:嗯,最终无论怎么对语言进行修订,其要义都是希望促进语言的不断成功。语言越成功,修改的代价就越大。随着你的不断成熟,再教育的成本就会变得更大,同时还有潜在的破坏代价,而这些成本和代价也会变得难以接受。如果你确实非常成功,那就更要小心提防所做的任何变化了。反之,如果你尚未成功,那么就有更大的自由空间来改变了。

JavaScript成为世界上最流行的编程语言纯粹是偶然。目前世界上JavaScript处理器的数量要高于任何其他语言。得益于其安全模型带来的种种问题,JavaScript是唯一一门可在任何机器上编写并运行的语言。 这些还嫌不够的话,再看看那么多嵌入了JavaScript的应用吧。Adobe的大多数应用都嵌入了JavaScript,这样就可以在本地编写脚本控制这些应用了。还有其他很多应用,不胜枚举。这么一看,JavaScript已经变得非常流行了。

JavaScript这门语言的问题在于推向市场以及标准化的过程都过于匆忙了。其大多数缺陷都没有出现在目前的实现当中——只存在于规范中。标准说照错的做,这听起来太吓人了,但这就是JavaScript的状态。它于1999年冻结了,接下来本应走向灭亡。但Ajax的横空出世改变了这一切,JavaScript变成了世界上最重要的编程语言。

于是,我们现在认为应该修复它。但这事应该是在2000年就开始做的,而那时并没有这么做,因为根本没人关注JavaScript。现在它已经长大了。

Web环境下的JavaScript还有一点非常怪异:如果编写服务器端应用、桌面应用或是嵌入式应用,你不仅需要选择语言,还要选择特定的编译器以及特定的运行时。但对JavaScript而言你别无选择,你必须在所有的环境下运行。

由于要在所有环境下运行,bug就没法修复了。如果某个浏览器厂商搞出个bug,他们会说“天啊,搞砸了”,下个月就会发布另一个版本,但我们却不能指望着所有用户都会升级。大多数人一旦在机器里装上IE就再也不会升级了,那些bug就会常年驻留在浏览器上。

Seibel:你希望JavaScript有哪些变化呢?

Crockford:我认为改进JavaScript最好的办法就是瘦身。如果我们能够取其精华,弃其糟粕,那JavaScript会变得更棒。我认为这个办法也适合于HTML、HTTP和CSS。我们应该仔细思考所用的各种标准,搞清楚需要哪些特性,遗漏了哪些特性并重新审视它们,绝不应该盲目地增加新特性。

代码阅读

Seibel:能否详细谈谈如何进行代码阅读呢?

Crockford:每次开会都让一些人阅读他们各自的代码,他们会引领我们查看其编写的所有内容,其他人则负责检查。对于团队的其他成员来说,这绝对是个学习的好机会,通过这个过程他们就可以知道自己的东西该如何与他人的相配合。

每个人都围坐在桌边,手里拿一叠纸,同时还把代码在屏幕上打出来,大家一起阅读。我们会在编写代码的过程中加上注释。有人会说“我看不懂这个注释”或是“这个注释与代码风马牛不相及”。大家的意见极具价值,因为作为开发者的你是不会阅读自己编写的注释的,你也根本没有意识到自己写的注释误导了读者。有这么多人帮助你编写整洁的代码是多么幸福的一件事啊——你会找到自己根本无法找到的缺陷。

我认为一小时的代码阅读抵得上两周的QA。这种剔除错误的手段真是很高效。如果你让能力很强的同事阅读代码,那么他们周围的新手们就会学到很多东西,而这一切是无法通过其他手段获得的;如果新手来阅读代码,那么他会得到很多极具价值的建议。

但这件事我们不能一直留到最后再做。回忆过去,我们会在项目完成之际安排代码阅读,但这个时候已经太迟了,只好取消。现在我深信代码阅读应该伴随着整个项目的生命周期。我花了很长时间才意识到这一点,这么做的好处不胜枚举。

首先,这么做有助于把控项目,我们能够真切地看到大家的进度,也能及早发现是不是有人已经偏离了轨道。

我曾经管理过一些项目,马上就到最后期限了,有人说“耶,马上就干完了”,然后我拿到了代码,发现里面什么都没有,有的也是一些垃圾,离完成还远着呢。管理层最厌恶这种事情了,我觉得代码阅读能够有效避免这种窘境的发生。

Seibel:那你需要指导别人如何进行代码阅读么?可以想象,既不想让代码编写者感觉受到侵犯,又能给出颇具价值的意见是很难的。

Crockford:没错,这需要给予团队成员充分的信任,要明确界定好边界。如果团队不和睦,那就别指望这么做了,这会导致团队分崩离析。如果还没有意识到团队的不和睦,那这么做很快就能发现。这个过程会让你学到很多,也会揭示出很多问题。起初会觉得不太自然,但一旦适应后就会觉得再自然不过了。 另外,我们要编写可读性好的代码。大家都知道,整洁很重要,而代码风格也同样如此。所有这一切会提升代码的质量并增强编程社区的能力。

Seibel:如何编写可读性好的代码呢?

Crockford:可读性有几个等级。最简单的一级是与表达保持一致,适当地保持缩进,在适当的地方使用空格。我有一个习惯来自于早年学习Fortran的时候,那就是,我往往会使用过多的单字母变量名,这个习惯可不好。我真的在很努力改掉这个坏习惯,但太难了——这么多年来还在与之斗争。

Seibel:有什么具体的举措可以提升代码的可读性呢?

Crockford:子集的想法非常重要,尤其对于JavaScript来说更是如此,因为这门语言包含了太多的糟粕,当然其他语言也一样。当还是个菜鸟时,我会翻阅语言规范并弄明白每个特性。我知道该如何使用这些特性并一直在用。但事实证明很多特性并非是深思熟虑的结果。

我现在想到的是Fortran,但其实所有语言都难逃这个宿命。有时语言设计者本身就错了。依我看来,C在设计上存在很多不妥之处。

Seibel:你如何阅读别人编写的代码呢?

Crockford:清理。我会把代码放到文本编辑器中并开始修复。首先,我会统一标点符号,适当缩进,等等这类的事情。我有些程序可以完成这些事情,但从长远来看自己完成会更加高效,因为这有助于我加深对代码的理解。Morningstar曾教会我如何完成这些事情。他非常善于重构别人的代码,并且这也是他所使用的方法,很好。

Seibel:你是否遇到过这种情况:看到代码写得一团糟,然后进行清理,但最后发现原来的代码其实写得很不错?

Crockford:还没遇到过。我认为随随便便写出来的代码肯定不好。好的代码意味着可读性要好。在某种程度上,如果我搞不懂代码的意图,那么写得再好也没用,有可能代码在我不关心的方面表现得很好,比如很高效、很紧凑,等等。

代码的可读性是我的第一要义。它比速度还重要,可以与正确性一争高下,可读性是正确性的重要前提。如果可读性不好,那就不是好代码,代码的编写者可能做出了错误的权衡。

Seibel:你偏爱K&R风格?

Crockford:是的,我认为他们是对的,其最初的风格没错,对于JavaScript更是如此。JavaScript会自动插入分号,这样如果将花括号放在左边而不是右边,那么程序的含义就会发生天大的变化,这种变化是很糟糕的。事实表明K&R风格不会遇到这个问题,但flush风格会。

对于JavaScript来说,花括号是有着正确的摆放位置的;而其他C风格的语言则不是这样,哪种摆放位置都可以看作是正确的。有些人喜欢flush风格的花括号,我也看过有人就风格的正确与否争论了半天,但这些解释都毫无意义,因为他们真正争论的是自己在学校里用的是什么、在第一份工作中又用了什么风格,或者是影响过他的某人使用了哪种风格,那这种风格就是正确的,而其他则是错误的。

这就好比是关于应该靠左还是靠右行驶的争论,结果当然是无疾而终。如果住在孤岛上,靠哪边行驶都无所谓,但如果大家能达成统一确定走同一边,整个社区都会受益无穷。

Seibel:在阅读代码时你会先排版,那你会对代码进行多大程度上的重构呢?

Crockford:我会重新编排代码以便所有东西都会在使用前声明和创建。有些语言提供了很大的灵活性,让你无需再这么做了。但这种灵活性我不需要。

Seibel:你曾在之前的一次演讲中引用了《出埃及记》第23章第10节和第11节的内容——六年你要耕种田地,收藏土产,只是第七年你要叫地歇息,不耕不种。并建议每次第7个sprint都应该用来清理代码。那什么时候做比较好呢?

Crockford:每6个周期——不管周期间是什么都该如此。如果你是每月交付,那么我觉得每隔半年都应该跳过一个周期,专门用来清理代码。

每个人的必修课:编程

Seibel:编程是不是越来越容易了,门槛逐渐降低?

Crockford:我对编程的兴趣在于帮助其他人编程、设计特定的语言或编程工具,这样会有越来越多的人能够从事编程工作——这也是Smalltalk的初衷。Smalltalk后来的发展方向出现了变化,但最初的方向确实吸引了我。我们如何设计一门面向儿童的语言,如何为那些并非程序员的人们设计一种语言?

Seibel:你是不是认为每个人都应该学习编程,至少了解一些?

Crockford:没错。当今世界快被计算机控制了,为了保护自己或是让自己更加全面,你应该了解这些东西的工作方式。

Seibel:有些人认为通过编程可以学到一种重要的思考方式,比如阅读和数学就是不同的思考方式,但都非常重要。

Crockford:我以前也这么想。在开始编程时我就有过这种想法:一切都是那么地井然有序,我看到了之前从未接触过的结构等东西。我在想“喔,这太神奇了。每个人都应该学习学习”,因为我突然之间感觉自己变聪明了。但不久之后,在与其他程序员交流的过程中发现,他们并没有开窍。程序员其实与常人也没什么区别,有时他们也会出现误解。当认识到这一点后我觉得很难过。

Seibel:那编程只是年轻人的专利么?

Crockford:过去我是这么认为的。几年前我患有睡眠呼吸暂停的症状,但没有意识到。我想可能是太累了,年纪也有些大了吧,结果发现自己的注意力很难集中,甚至都没法编程了,因为我的大脑没法承载太多的东西。很多时候编程都需要先在脑子里想好,然后再写出来,但我却不行。

我丧失了这种能力,想当然地认为是年龄太大的缘故。幸好,病情得到了好转,于是我又开始编程了。现在的我编程水平可能比以前还要好,因为我知道如何不过多地依赖于记忆。现在的我更喜欢将代码文档化,因为我不敢保证下一周还能记得写这些代码的意图。事实上,有时我会检查自己的代码,但会惊讶于自己怎么会这么写代码:我压根就不记得自己曾经这么写过,这些代码有的非常丑陋,有的却非常优雅。我实在不知道怎么会这样。

Seibel:你曾说过文学编程就像Donald Knuth所说的那样,是个非常棒的想法,那你使用过文学工具么?

Crockford:没有。我一直在考虑这个问题,并为我所使用的一些语言设计过文学工具,但我现在并没有从事文学编程工作。

Seibel:这仅仅是个工具链问题么?如果有现成的工具,你还会编写文学程序么?

Crockford:当然会了。比如说,如果使用文学风格编写JSLint的话,那维护工作就轻松多了。我所说的文学风格是指在设计程序时要特别考虑到阅读问题,这么做会给程序带来巨大的价值。

Seibel:你觉得文学编程工具的主要特征是什么?

Crockford:Knuth的主要贡献在于提出了以各种顺序编写代码的想法。这样,如果我所关注的东西涉及很多地方的代码,那么我会将这些代码整合起来并加以说明,然后工具会在适当的地方解决细节问题。 他还帮助你摆脱了函数大小的困扰。理想情况下,一个函数不应该超出屏幕的范围,这样就能一览无余了。如果达不到这个要求,那可以将一个函数拆分成多个函数,如果函数对程序结构起不到什么作用,那么它也没有存在的价值。

Knuth建议抓住函数的各个方面,它们很可能是紧密相关的——具有一致性,但就是太大了;有时函数确实过于庞大——他建议使用具有描述性的标签来表示每个函数,“这个函数是:”,然后列出这些标签。你当然可以使用函数达成目的,但这两者并不一样,如果使用函数,你必须要处理函数之间的通信,等等。这么做会引入更多与问题不相关的结构。

最后,我非常希望看到新的文学编程语言的出现。Knuth非常擅于将这些想法应用到Pascal和C当中,但我打心底想看到有人能真的设计出一种新的使用这种风格的语言。

Seibel:你读过Knuth的文学程序么?

Crockford:当然读过。

Seibel:如何读的?像小说一样?

Crockford:没错,就像小说一样。我像在读他的散文而非程序,喜欢他的展现方式,他写得确实好,偶尔还会搞个笑话出来。我很享受这种阅读体验。

Seibel:Knuth的大部头《计算机程序设计艺术》如何?你是从头到尾读过这本书呢,还是将其作为参考随时翻阅,抑或是把它束之高阁碰也不碰呢?

Crockford:除了你说的最后一种情形之外。在上大学时,有那么几个月我连房租都没交,就是为了买他的书。我读过这些书,从中得到了不少乐趣,比如在第一卷的索引有个关于拖车的笑话就很好玩。我到现在为止还没能把书上的内容全部搞懂。Knuth对某些地方的研究要比我深入得多,但我还是喜欢这些书并把它们当作参考资料。

Seibel:你是从头到尾逐字阅读,跳过那些不理解的数学部分?

Crockford:是的,我会很快略读过星号太多的部分。我试图将熟悉Knuth的书作为招聘标准,但结果却大失所望,根本没几个人读过他的书。依我看来,任何自称为专业程序员的人都应该读过Knuth的书,至少也应该买过他的书。

Seibel:也就是说Knuth讲述的是如何实现最根本的东西,然后才有全景。即便清理了平台,但使用理性的方式构建大型系统和设计也是非常困难的。请问你是如何设计代码的?

Crockford:编写程序与对程序的生命周期进行迭代是不同的。通常,编写软件的原因在于我们知道将要修改它,而修改任何东西都不那么容易,因为很多时候修改意味着打破旧有的东西。

你不能期望使用这种方式完成所有事情,但还是应该尽力保证足够的灵活性,这样不管做什么都能适应。这就是我的观点。如何避免误入死胡同?如何保证灵活性?

这就是我喜欢JavaScript的原因之一。我发现JavaScript可以轻松实现重构,而重构一个继承层次很深的类实在太痛苦了。

Seibel:你觉得自己是个科学家、工程师、艺术家、工匠还是什么?

Crockford:我觉得自己是个作家。有时我使用英语写作,有时使用JavaScript。归根结底,这完全取决于交流方式以及为了促进这种交流所采取的结构。人类语言与计算机语言在很多地方都是大相径庭的,我们需要阅读计算机语言,因此必须与之交流,我根据语言的这种交流能力判断计算机程序的优劣。在这个层次上,人类语言与计算机语言的差别不大。

Seibel:你对自学的程序员有什么建议呢?

Crockford:两个字:多读。现在有不少好书,去找些好书来看吧。如果从事Web开发工作,请找一些优秀的站点,看看他们的代码。话虽如此,其实我不太想这么建议。大多数Web开发者都是从“查看源代码”开始走上Web开发之路的,但直到现在,大多数源代码的质量都是非常低劣的。因此有一代程序员都被那些低劣的示例误导了,他们写的代码质量也不高。现在的情况已经有所改观,但依然有很多低质量的代码游离于你我之间,所以我是不太想给出这个建议的。


参考:

http://www.ituring.com.cn/article/39021

你可能感兴趣的:(JavaScript权威Douglas Crockford:代码阅读和每个人都该学的编程)