最有价值的编程忠告(来自贝尔实验室Plan 9操作系统的创始人Rob Pike)

Rob Pike，目前谷歌公司最著名的软件工程师之一，曾是贝尔实验室Unix开发团队成员，Plan9操作系统开发的主要领导人，Inferno操作系统开发的主要领导人。他是缔造Go语言和Limbo语言的核心人物。下面是他分享给大家他在贝尔实验室工作的一段经历，这段经历改变了他对bug调试的思想认识。

Job的主要工作经历：

我在贝尔实验室工作了很多年。我在计算机科学研究中心，你会很诧异，这是个很小的实验室，但这里却创造了Unix，我来到这里工作的时候Unix已经发布了第七版。从2002年起我来到谷歌工作，主要开发一些系统基础架构。

最主要的成就：

我最为人所知的应该是我和Brian Kernighan(Unix开发组的重要成员)合著的两本书：《The Unix Programming Environment》 和 《程序设计实践(The Practice of Programming)》 (30年后的今天仍在印刷出版！)，影响范围最广的一件事应该是我和Ken Thompson共同开发完成了UTF-8编码格式。在其它方面，诸如计算机图形，操作系统，软件开发工具等上也做了大量的工作，最近在给谷歌开发Go编程语言。

使用最多的编程语言：

长久以来，C语言是我编程的选择，但在我的编程生涯里，我使用过很多种语言。而目前我开发d 东西基本上都是用Go语言，这是我见过的最高效的一种编程语言，它在我的工具箱里已经完全取代了C语言的位置。

忠告：

在我加入贝尔实验室一年多后，Gerard Holzmann设计了一个很小的交换式制图语言，我开始和Ken Thompson一起在开发针对这种语言的即时编译器上做结对编程。我打字比较快，所以我坐在电脑前，Ken站在我身后看我编程。我们开发的很快，但经常会遇到问题，而且可以看出来出错了——毕竟这是一个图形化的编程语言。当程序出错时，我本能的一头扎进问题，检查报错跟踪信息，添加调试打印语句，启动调试器，等等，但Ken只是站在那思考，完全不理会我也不查看我们写的出问题的代码。一段时间后我发现一个规律，Ken经常会比我先找到问题出在什么地方，而且会突然的喊一嗓子，“我知道什么地方的问题了。”每次他的判断都很准确。我认识到，Ken已经在脑海里构建了代码的模型，当有问题出现时，那是他脑子里的模型出了问题。在思考为什么会发生这些错误时，他能凭直觉找到模型中什么地方不对或发现写的代码跟这个模式什么地方有出入。

Ken教会了我一个极其重要的习惯：纠错前先思考。如果你一头扎进问题中，你可能只解决了当前出现问题的代码，但如果你先思考这个错误，这个bug是怎么引入的？你通常发现和纠正一个更高层次的问题，进而改进了系统设计，防止了更多bug的出现。

我认识到这种编程思考模式非常的重要。有些人痴迷于一行行的、使用各种工具来调试所有的东西。但我现在相信，思考——不看代码的思考——是最好的调试途径，因为它能让你开发出更好的软件。

英文原文：

Rob Pike, now a Distinguished Engineer at Google, worked at Bell Labs as a member of the Unix Team and co-created Plan 9 and Inferno. He was central to the creation of the Go and Limbo programming languages. Rob shares an experience at Bell Labs that changed his approach to debugging.

Be sure to check InformIT for a new article every Wednesday. See more advice from other programmers  here.

Name:

Rob Pike

Job Experience:

I worked at Bell Labs for many years. I was in the Computing Sciences Research Center, the (surprisingly small) lab that created Unix, although I was not there until after the Seventh Edition was released. Since 2002 I've been at Google, working on various pieces of infrastructure and infrastructure infrastructure.

Most Notable Achievement:

I'm probably best known for my books with Brian Kernighan, The Unix Programming Environment(still in print almost 30 years on!) and The Practice of Programming. The most widespread thing I've done was develop UTF-8 with Ken Thompson. But I've also done significant work in computer graphics, operating systems, software tools, and most recently helped develop the Go programming language.

Most Frequently Used Programming Language:

For too long to admit to here, C was my language of choice, but I have used many languages through my career. Nowadays almost everything I write is in Go; it is the most productive language I have ever used and has displaced C completely from my toolbox.

Advice:

A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.

I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.