来源：图灵社区

本文约5200字，建议阅读10+分钟

只为编写更少的代码。

本系列文章是由Informit以“我收到的最佳编程建议”为主题发起的专访活动，发布于2012年。现在看来，关于采访中谈及的一些职场规则，阅读经验，编码技巧等方法论仍然适用于当下。那么，请放下手头的工作，听听这些高级开发者们的故事和建议。

千万别碰其他人的代码！ ——Russ Olsen

调试前的思考十分重要——Rob Pike

编写更少的代码。——Erik Buck

阅读的资料一定要比你编写的内容多得多，而且要坚持阅读高质量的资料。——Danny Kalev

……

今后，千万别碰其他人的代码！

Russ Olsen作为《Eloquent Ruby》一书的作者，同时也是一名Clojure开发者。他把一个与古老的CAD程序、办公室政治及其进展有关的故事娓娓道来，整个故事可以总结为一句简单的口头禅：“千万别碰其他人的代码！”

Russ Olsen

编程能力及工作经验：

从穿孔卡片到ClojureScript无所不能。

最显著的成就：

《Ruby设计模式》和《Eloquent Ruby》的作者

最常用的编程语言：

Ruby为首，Clojure紧随其后。

建议：

我收到的最佳编程建议来自于我的职业生涯早期，那时我正在一个令我爱恨交加的系统上工作。那个系统最酷部分是我们正在做计算机辅助设计——想象一下Adobe Illustrator，不过它是为工程师设计的。那时候，具有交互式图形的CAD软件堪称高科技的顶峰。

让我痛恨的事情是，系统很慢、慢得令人抓狂：你会坐在那里，看着画面中一条接一条地出现令人痛苦的线条。完成一个简单的绘图会花费几十秒，然而当显示复杂画面时，你就有机会去喝杯咖啡慢慢等了。即便我们用早期的计算机标准来衡量，该系统的性能也是极其糟糕的，这一定传达了某些信号。如果是黑客（hacker）会做些什么？而你又该做些什么？

我所做的就是仔细查看代码。尽管图形部分不是我的职责范围，但是我花了数个夜晚和周末乐此不疲地钻研此问题，设法弄清系统如此缓慢的原因。我并没有花很长时间就找到了这个问题：一旦你启动该系统，你实际上就开启了两个进程。一个进程是正常的CAD系统，而第二个进程则用于完成与绘图功能有关的全部工作。这两个程序彼此之间通过某种类似套接字（socket-like）的网络连接进行通讯。

显然，开发图形子系统的程序员已经爱上了客户端/服务器（client/server）风格的程序，并且已经在我们的CAD系统中如法炮制了他自己的程序。问题在于，由于我们是在这种早期硬件上运行该系统，因此将全部绘图压缩为一个有限的套接字要耗费我们一个数量级的性能，然而我们对正在付出的成本却给不出充分的理由。

我用接下来的整个周末将把系统整合到一起，这个版本中所有的内容被打包到单个进程中。系统的变化更是引人注目。现在，简单图像差不多瞬间就能绘制出来，然而更为复杂的图像也只需抿口咖啡的工夫就能完成。星期一早上，我一遍又一遍地演示我的整合版本：首先是给我的老板演示，接着是我老板的老板，然后又是他的老板，直至全体高层领导。

然后就大难临头了。许多那些老板的老板的老板非常生我的气，但是没有人可以或打算阐明个中缘由。我的一些同事见到我就像见了瘟神一样，避之唯恐不及。慢慢地我想通了，我已经闯入一些错综复杂的跨部门权力斗争之中。因为我用我自己的笨方法并没有给图形处理加速，而是为某个组织派系提供了制胜法宝，同时也让其他派系感到很不爽。最终，他们勉强地将第二个进程连同套接字（socket）一起移除了，从而我们获得处理速度更快的图形。不过兴高采烈的人却寥寥无几。

就在那时，所有员工的最大老板要我去他的办公室走一趟，并送给了我一个关键的建议。随着办公室的门牢牢地关上，他转过身来，二目圆睁地看着我，然后说道：

“今后，千万别碰其他人的代码！（In the future, stay the Hell out of other people's code.）”

实际上，这是个很糟糕的建议，从那以后的数年中，我都以自己的方式对它置之不理。不过这些话还是有价值的，因为我曾多次回忆起它们。

每当一些恼人的新员工带着一个明显行不通的馊主意来找我时，“千万别碰其他人的代码！”这句话就会在我的脑海里回荡，而且声音越来越大。

每当其他工程师对我的代码有见解时，我记得当时心里是这么想的，你应该管好你自己的技术工作，但同时我又力求解除我的自尊心。

在后来的那些年里，随着我自己也在建立并管理软件开发团队，我已经意识到，对于那种古来的项目而言，可能会有整整一打程序员都知道系统到底为何如此缓慢，而且也知道该如何修复它。尽管他们心知肚明，但是他们却把解决方案烂在肚子里。因为在那种组织里，与让系统变得更好相比，还有一些更重要的事情（派系之争、办公室政治等等）要关注。“今后，千万别碰其他人的代码”，这句话假设将会有未来。

但是，拥有未来的最好方法是让以下内容成为团队的一部分：

• 看重系统进步高于办公室政治（progress over politics）

• 奇思妙想高于固步自封（ideas over territory）

• 自告奋勇高于彬彬有礼（initiative over decorum）

调试前的思考十分重要，为代码建立心智模型

Rob Pike现在是Google的杰出工程师，曾是贝尔实验室（Bell Labs）Unix团队成员之一，此外他还参与开发了Plan 9及Inferno两款分布式操作系统。他是创建Go及Limbo两款编程语言的中流砥柱。Rob分享了在贝尔实验室工作时的一段往事，从此改变了他的调试方法。

Rob Pike

工作经验：

我曾在贝尔实验室工作多年。我就职于计算科学研究中心，正是该（规模小得惊人的）实验室创建了Unix，不过直到Unix第7版发布（1979年）以后我都不在那里。自2002年以来，我一直在Google，从事与各种零散的基础设施、以及基础设施之基础设施相关的工作。

最显著的成就：

在我的著作中，或许最为人所知的就是与Brian Kernighan合著的《UNIX编程环境》（The Unix Programming Environment，于1983年11月01日出版，至今将近30年了仍在重印）、以及《程序设计实践》。我做过的应用最为广泛的成果就是与Ken Thompson一起研发的UTF-8编码。不过我在以下方面也完成了重要工作：计算机图形学、操作系统、软件工具，并在最近帮助研发了Go编程语言。

最常用的编程语言：

由于使用了太久，在这里不得不承认C语言是我最常用的编程语言，不过在我的职业生涯中我曾使用过许多不同的语言。如今，几乎我所编写的一切都是用Go语言完成的；Go语言是我使用过的最具生产力的语言，而且它已经彻底取代了C语言在我工具箱中的位置。

建议：

那是在我加入该实验室一两年后，当时我正在与Ken Thompson结对编程开发一款即时编译器，该编译器用于一种由Gerard Holzmann设计的小的交互式图形语言。由于我打字速度更快，因此当我们编程时，由我执掌键盘，而Ken则站在我的背后。当我们紧张工作时，一旦哪里出了问题通常都是看得见的——毕竟那是一种图形语言。每当某些地方出错时，我会本能地开始探究那个问题，如检查堆栈跟踪、添加打印语句、调用调试器等等。不过Ken却只是站在那里思考，无视我以及我们刚刚写下的那些代码。

经过一段时间，我注意到一种模式：Ken经常会先于我理解问题所在，还会突然宣布，“我知道是什么错了。”他一般都是正确的。我意识到，Ken为那些代码构建了心智模型，一旦哪里出了问题必定是该模型中出现了错误。通过思考怎样有可能发生那个问题，他会凭直觉知道此模型在哪里出了错，或是我们的代码在哪里必定没有满足此模型。

Ken教导我，调试前的思考十分重要（thinking before debugging is extremely important）。要是你一头钻进错误，你就会倾向于修复位于代码中的片面问题，但是如果你首先琢磨该错误，考虑该错误是怎么来的，你通常会发现并修正代码中更高层次的问题，那将会改善设计并防止进一步的错误发生。

我承认这很大程度上是风格问题。有些人坚持以逐行工具驱动的调试方法来处理一切错误。但是，现在我相信，思考——不看代码——是最好的调试工具，因为它会导致更好的软件。

编写更少的代码

技术是为了让事情变得更容易，而不是更费力！Erik Buck作为《Learning OpenGL ES FOR iOS》一书的作者、连环创业者、艺术家、以及可替代燃料汽车的创造者，他讨论了编码中的生产力和效率。

Erik M. Buck

工作经验：

我参与编写了《Cocoa程序设计》及《Cocoa设计模式》两本书。我的最新著作《学习OpenGL ES FOR iOS：现代三维图形编程动手指南》将在八月份上架。

我在1993年创立了我的首家公司，而且在将其知识产权出售给世界500强的竞争对手之前，就已把它打造成为航空及娱乐软件行业的领导者。我正在进行中的工作包括：给八年级的学生讲自然科学、展出油画肖像、以及开发可替代燃料汽车。我最新创办的企业是cosmicthump.com。我还是莱特州立大学的计算机科学兼职教授，并讲授iOS编程。

我拥有二十年以上为实时嵌入式系统设计及开发C++软件产品的经验，而且我是Objective-C编程语言的铁杆粉丝。

建议：

编写更少的代码。（Write less code.）

Steve Jobs广为人知的一句话是，“那种写起来最快、从不出问题、无需维护的代码行就是你永远都不必编写的代码行。”

来想一想有关Richard和Jane的寓言。在周一早上，两人都收到了修复用户报上来的某个高优先级的软件缺陷。Richard很快就发现了该问题。在周二，Richard已经设计出一款会影响三个模块的补丁。在周三，Richard写完了几百行代码，并准备在周四一早开始测试。周五中午，已通过所有测试，而后该补丁被作为紧急“修复程序（hot fix）”准备部署。

相比之下，周一Jane早早就下班了。周二她为安排公司的新健身中心会议用掉了大部分时间。周三Jane打电话请了病假，不过看过医生以后，周四她觉得好多了。周四中午她着手分析软件问题。周五早上，Jane删除了一行引发该问题的代码，然后系统通过了所有测试。到底哪位程序员更有成效？尽管大多数公司会奖励Richard，然而Jane的成效则要大得多，而且为公司节省了数不尽的长期维护成本。

阅读高质量的资料一定要比你编写的内容多得多

Danny Kalev是《ANSI/ISO Professional Programmer's Handbook》及《The Informit C++ Reference Guide: Techniques, Insight, and Practical Advice on C++》两本书的作者，他分享了一些建议，对那些寻求提高自身专业技能的程序员大有裨益。

Danny Kalev

工作经验：

我从1988年以来一直在编程。我最初编程用的是DEC VAX 11/750（1980年10月推出）的机器，即便在当时那台机器也算是老古董了。然而，它却是学习编程的绝好方法，因为它支持多种不同的编程语言，例如PL/1（我仍然喜欢）、DCL（DEC的专有脚本语言）、Fortran、以及后来的C语言。

20世纪90年代中期，我参与了一个规模巨大的移植项目，该项目是将以色列内政部办公室的国民登记处数据库转换为现代的、客户端/服务器架构。它是使用C++的最早期项目之一（在1994年）。

之后我先后跳槽到几个专注于多媒体流的新兴创业公司——多媒体流在20世纪90年代末期是个热门话题。在那以后，我成了个体户。我已经写过三本C++的书，而且于2003年在Informit上开办了C++每周专栏，延续至今已有九年多。如今，我是几家IT公司的顾问。我主要的专业技能领域仍是C++及面向对象设计。我还会举办与这些主题相关的讲座。

建议：

如今每当我编写新的C++代码时，我会意识到同一程序与两三年前的样子相比差别是如此之大。那是因为C++的变化很快，即便是存在了30年后的今天依然如此。然而不仅仅是C++标准的变化影响着我的C++代码。作为程序员，我们始终在学习如何改进我们的做法,有两个因素导致了需要持续阅读——语言变化及技能改进。

要是你想成为优秀的程序员，你就必须投入大量时间去阅读C++杂志、一流作者的新书、订阅专业讨论组及论坛的内容、并与你的同事互相切磋。学习是永不结束的持续过程。除了接触新的编程技术和设计风格、阅读专业资料以外，还要自习精准的技术术语（technical terminology）。例如，规范4则（canonical four）（特指构造函数、析构函数、拷贝赋值运算符、赋值运算符）被作为那些特定成员函数的正式名称。同样地，C++中没有方法（method）——它只有成员函数（member function），因此我发现我总是把那些仍在谈及方法和属性的人搞得一头雾水，然而在C++中方法和属性都不存在。这并非吹毛求疵或偏执——没有精准、专业、统一的术语，你将无法阅读你的编译器的在线文档，更不用说专业性更强的资料了，例如C++标准本身的文本内容。

总而言之，阅读的资料一定要比你编写的内容多得多，而且要坚持阅读高质量的资料（read much more than you write, and stick to high quality material）。对那些侮辱你智商的烂书说拜拜，抬高专业水准，着眼于最专业、最新资料。那么做就对了。

查看更多：

http://www.informit.com/promotions/experts-in-programming-share-their-knowledge-with-the-138930

编辑：黄继彦

校对：王欣