[译文]开发者见解系列，第2部分：谈谈编码（上）

原文：The Developer Insight Series, Part 2: Code Talk

作者：Janice J. Heiss

出处：http://java.sun.com/developer/technicalArticles/Interviews/devinsight_2/

 

历年来，我听到过开发者讨论他们最喜欢的代码、最有趣的代码、最酷的代码，以及如何编写代码，如何避免编写代码，编写好代码的障碍，以及与编写代码相关的爱恨情仇等等，在开发者见解系列的第一部分中，三位Java Champion就Brian Goetz的关于编写“傻瓜式”代码的建议给予了积极的响应。

在第二部分中，我们会听到来自五位杰出的开发者的编码建议：Joshua Bloch和Masood Mortazavi响应Goetz的保持代码简单的建议，Jaron Lanier和Victoria Livschitz想从根本上改变创建代码的方式，而著名的错误修复专家Brian Harry在强调过程能教给我们什么的同时提供了一些关于错误修复的贴士。

 

目录

 

-           Joshua Bloch：谨防盲目乐观

-           Masood Mortazavi：最好的代码所做的假设最少

-           Jaron Lanier：我们思考软件的方式是错误的

-           Victoria Livschitz：编程语言不仅仅是面向对象那么简单

-           Brian Harry：在修正错误时，查明平台的较早版本

-           其他参考

-           评论

 

Joshua Bloch：谨防盲目乐观

关于Joshua Bloch：

Joshua Bloch是Google的首席Java架构师，他作为Effective Java（现在已出第二版）和Java Puzzlers（与Neal Gafter合著）两书的作者而为人所知。在之前作为Sun Microsystems高级职员的生涯中，他是一位工程师，并且是核心Java平台组的架构师，他设计并实现了获奖的Java Collections Framework，参与java.math包的工作，并为该平台的其他许多部分做出了贡献。

Bloch拥有Carnegie Mellon大学的计算机科学博士学位，他的书Effective Java是Java开发者中大受欢迎的经典。

 

您说过Java开发者中的一个常见毛病就是不自觉地要去进行代码优化，结果则是得到不必要的复杂化了的更慢的代码。为什么开发者会错误地去优化代码呢？

 

要成为一个软件开发者，你就必须是一个乐观主义者——否则，就会像是在进行一场失败的战争。通常情况下，这是好事，但它也有不好的一面：乐观主义可能会导致过度自信，容易觉得那些关于过早优化的常规警告并不是针对你而言的，因为你会知道哪些代码是时间关键的，并且知道如何让它快速运行。不过，在没有对每一项企图优化进行测量前后的对比的情况下，是没有人能够确定这一点的。

 

您提到的另一个毛病是，在有相当好的代码库存在时，开发者还在编写他们自己的代码，为什么开发者会这样做呢？

 

有两个原因，到目前为止最常见的原因是，开发者不知道代码库的存在，就开发者来说，我觉得现在外面有那么多的代码库，是不可能都知道他们的存在的，就是说，很难搞清楚这样的一些便利性，即是否值得花精力去弄清楚是否有这样的代码库存在。特别是对于涉及到并发的地方来说更是这样，专家们花上整整几个月的时间来编写显然是很普通的一些并发工具这种情况并不少见。

当面对这一类功能的需要时，聪明的开发者会尽一切努力来寻找某个适当的代码库，但总是容易碰到不容忽视的并发代码错误，且由此产生的错误几乎不太可能被检测到。

第二个原因是，开发者倾向于推倒重来，重新去发明轮胎，这也是他们倾向于过早优化的原因。为了尽量明智一些，大多数的开发者都保持着我能做这样一种态度，但有些人则做得太多了，他们对自己说：“是的，是有一个代码库，但我能做得更好。”也许你可以，但并非意味着你就应该做，除非确实是非常地不适合你的需要，否则就使用标准的代码库吧。

 

是否是思考问题的方式把开发者带入困境中的呢？

 

我觉得最常使开发者陷入困境的思考方式是盲目的乐观，自然而然地认为程序只会做正确的事情，但机器并不能读懂你的想法，大部分系统提供的设施都有相当的局限性，这一点你是应该要知道的。例如，int和integer并不是一回事——可以有无限多个整数，但只有2³²个int值，这意味你需要担心溢出，举例来说，你可能会认为这个循环恰好只遍历每个int值一次：

 

for (int i = Integer.MIN_VALUE; i <= Integer.MAX_VALUE; i++)

    doSomething(i);

 

但不是，这是一个无限循环，因为每个int值都小于或者等于Integer.MAX_VALUE，一旦循环到了Integer.MAX_VALUE的话，int值就返回到Integer.MIN_VALUE并重新开始另一遍循环。这仅是这种思考方式的一个简单例子，但应用到语言和类库的各个方面的话，都会带来同样令人不快的结果。

 

可参阅对Josh Bloch所作的两个完整访谈：更有效的Java和Java解惑。

 

Masood Mortazavi：最好的代码所做的假设最少

 

关于Masood Mortazavi：

Masood Mortazavi是Sun公司的软件工程经理，开始时他加入公司的Java EE开发团队工作，后来成为持续可用性问题以及电信与Java软件组合作方面的专家；近年来，他管理多个工程师团队，致力于多种开源数据库如Apache Derby、PostgreSQL以及MySQL等。

他拥有应用和化学工程方面的B.S.（加州大学圣地亚哥分校）学位和M.S.（加州大学戴维斯分校）学位，以及计算流体动力学（加州大学伯克利分校）方面的Ph.D.学位，另外，他还拥有新闻专业（加州大学伯克利分校）硕士学位和M.B.A（加州大学伯克利分校）学位。后来他花了数年时间来获取第二个Ph.D.学位，这是加州大学伯克利分校科学逻辑学和方法论研究生部的博士学位，致力于数学、计算理论和哲学的基础研究。

 

在编写代码的时候，我常常不得不把重点放在逻辑结构、具体的算法和程序动态方面，既然我们是在创建系统行为并为其编码，我通常感觉就像是正在写某种类型的法律论证似的，因此，即便要做假设的话，那么最好的代码也是做了最少假设并且只做了绝对必需的假设的代码。

对逻辑学家来说，把程序看成有约束变量和自由变量的谓词结构是很有帮助的，所谓Java中的好“方法”或者其他传统的编程语言中的好“函数”是避免了局部变量的方法或函数，他们只为内部的簿记功能服务。我们做了越多的内部簿记，我们的程序就越详细，这就意味着代码开始要求我们把它拆分成更多的类和方法。

 

可参阅对Masood Mortazavi所作的完整访谈的第1部分和第2部分。

 

Jaron Lanier：我们思考软件的方式是错误的

 

关于Jaron Lanier：

Jaron Lanier以他在虚拟现实方面的工作而为人所知，虚拟现实是他在1980年代创造的一个术语，作为一个著名的作曲家、音乐家和艺术家，他曾任教于美国各地多所大学的计算机科学系，其中包括耶鲁大学、达特茅斯学院、哥伦比亚大学以及佩恩大学等。他曾作为National Tele-Immersion Initiative（NTII）的首席科学家工作，NITT致力于在其他事物中使用计算机来使得不同城市中的人们体验他们的身体位于同一地的那种幻觉。2001年到2004年，他曾是Silicon Graphics Inc.的访问科学家，在那里他开发了临场感和远程沉浸核心问题的解决方案。Lanier在2006年获得了New Jersey Institute of Technology的荣誉博士学位，他是2001年Carnegie Mellon大学的沃森奖的获得者，并且是2005年第一届Edge of Computation Award的最终角逐者。

他最近的工作是在研究其所称的“phenotropic计算”，在这一研究中，作为现有协议遵守的软件模型被作为软件系统连接组件的方式的模式识别所取代。他目前是加州大学伯克利分校的Entrepreneurship & Technology中心的跨学科驻校学者。

 

我认为我们编写和思考软件的整套方法都是错误的，如果你了解一下现有事物是如何工作的话，就会发现一个奇怪的现象：没有人——我的意思是没有人——能够真正以可靠的方式创造出大的程序。如果我们不找出另一种不同的方法来思考和创造软件的话，我们将不能写出大于大约二到三千万行代码的程序，无论我们的处理器变得有多快。

目前这种可扩展性的缺乏是一种全球性的负担，我们的行业存在着垄断，因为对于任何个人来说都是如此难于参与竞争，编写大型软件应用是如此的不容易。不过这对我来说很奇怪，如果你看看人们创建的其他事物，例如炼油厂或是商业飞机等，我们能够有效处理的复杂性是远远超过软件的复杂性的。

软件存在的问题是，我们从来没有学会如何控制选择的副效应，我们称之为bug，我们不应该满足于这一现状，我仍然相信，有一些想法等着我们去创建，总有一天我们会有一些新的编写软件的想法是克服了这些问题的，这是我的主要专业兴趣，我想贡献一些力量来使bug消失。

 

难道bug不是只不过是人的思维局限吗？

 

不不，他们不是，bug和变异或缺陷之间的区别是什么？如果你考虑到这一点的话，如果你对某个程序做了一个小改动，它会在程序的行为方面导致巨大的变化。如果自然以那样的方式运作的话，宇宙时时都会崩溃，当然就不会有任何进化或生命。方法复杂性的事物在自然中逐步建立了起来，这样的话，如果你有一些小改变的话，它只导致足够小的结果，它可能会有逐渐的演变。

现在，我们有了一点——不是全部——只是一点基因型和表型之间的线性连接，如果你想用这些术语来表达的话。但在软件中，在源代码（“基因型”）和观察到的程序效果——你可能会称之为程序的“表型”，在他们之间存在着混乱无序的关系。

而这一混乱真正地困住了我们，我不知道我到底会不会有个解决该问题的好主意，我正在研究一些事物，不过你知道，最能引起我关注的问题是，在程序员中缺乏该问题最终能够被解决这一信心会意味着什么。在过去的几十年中，一直存在着一种陷入自满情绪的状况，随着新的几代程序员的出现，越来越多的人接受了事情就是这样的并且将会永远这样的想法，也许这是真的，也许这无法避免，但这不是已知的，对我来说，对bug的那种自满情绪就是编程顶上的一片乌云。

 

可参阅对Jaron Lanier所作的完整访谈：第1部分和第2部分。