One more struggle, and I am free
我已向Wired付费获得授权，翻译文章版权为译者本人所有，未经许可，不得转载。
1
Russel Guy怀抱着装满25万美元的公文包，来到爱沙尼亚的塔林市附近的直升机坪时，一架军用直升机已经停在那里了。Guy感觉不太自在，这里怎么看也不像军事基地，但是旁边站着的一看就是军人，而且带着枪。
这是1989年。苏联行将崩溃，部分军官正忙于出卖物资。Guy走近直升机坪的时候，大多数物资已经从直升机上卸下来，瓜分完毕。Guy想要的东西正是剩下的那些大箱子。他打开一个箱盖看货，闻到浓重的松树味。箱子里装的是另一个箱子，箱子之间垫着松针。Guy想，装货的人以前一定对付过缉毒犬，不过现在，他要的货可不是毒品。
苏联军方秘密制作了全世界的地图，但是迄今为止，只有少数外人见过这些地图。
这些箱子里都是地图，有几千张之多。每张地图的右上角都印着红色的俄文секрет，意为“机密”。
原文：Why I Love Reading Other People’s Code And You Should Too by Alan Skorkin
翻译：Yurii
我恨读代码
我发现，许多程序员都讨厌读代码——拜托别掩饰了，承认吧。差不多每个人都喜欢写代码——写代码乐在其中。可是，读代码真是不容易，而且还很烦人，又无可逃避，其他人写的代码总是很垃圾（即便不说，我们心里也这么想的）。即使自己写的代码，过几个小时再看也有点垃圾，过的时间再久点，就更垃圾了。那么，还有什么理由去看别人的蹩脚代码，而是不自己写几手漂亮的？能不能暂且忽略这个问题，花上几个小时看别人的代码，再回头来看自己的是不是还那么漂亮？即便有位大师坐在你面前，如果你不能从他身上学习，你永远也成不了大师。办法之一就是找到这么一位大师，让他手把手地教会你全部知识。有这可能吗？——当然有，只是很难遇到这顶好的运气。不过你也不必奢求那么幸运，做程序员这行就很幸运，因为大师们的所有思想和技艺都凝铸在他们的代码里，供我们学习。你要做的只是阅读代码——当然，如果有人给你一点点地讲肯定更节省时间，但这基本属于痴人说梦。换句话说，要相当个好木匠，得仔细研究大量的精美家具。
我热爱读代码，我总是直观地认为读代码的收获很大，没错，它可能有点讨厌甚至烦人，但你的收益绝对大过这点麻烦。举个例子，你要当大作家，是不是只关心自己写东西就够了？你可以试试看，但是估计不会折腾不出什么名堂。公认的事实是，多数大作家都是会如饥似渴大量阅读的。想写出好的作品，必须先阅读其他大作家的作品，吸收不同的风格，了解他人的尝试，然后才可以培养自己的创造力。这样，你的知识才能逐渐积累，最终你写的东西才有几分成熟，你也才会找到“感觉”。写代码也是这样，如果你不去阅读那些伟大的代码，怎么可能把程序写的漂亮？阅读伟大的代码之于程序员，就如同阅读伟大作品之于作家（我不敢掠美，这句话是Peter Norvig(译注：Peter Norvig是著名的Lisp程序员，现任Google研发总监)说的，他可不是个简单人物，所以好好记住这句话吧）。
即使上面说的你都不信，但有个事实无可否认。要想当个称职的开发人员，能熟练阅读代码是非常重要的。如今，只要不是闹着玩的项目，都是团队协作的成果，所以总会有这样的代码：它不是你写的，但你必须跟它打交道，去修改，或者去扩展。于是，阅读代码很可能就是你身上最重要最常用的能力了，咬紧牙关练好这门本事吧——而且，要快。
我都说不清有多少次见过这样的事情了：程序员把一段不熟悉的代码上下拖动，几分钟之后仍然一脸迷离。不久他们就宣布，这段代码根本没法看懂，更不必浪费时间了，可以想办法绕过这个问题。我不知道他们真正要做的是什么，一点点弄明白这段代码的意思，还是睁大眼睛等着开窍？阅读代码不靠成年累月死盯着看，你要做的是弄懂它，把它变成自己的。下面说的是我用的一些技巧，但不是全部，不过我觉得这些非常有用。
看代码看到目光迷离
1. 尝试亲自构建和运行程序。通常这一步很容易做到，比如你看的是真正运行的工作代码时（而不是不知来源的古怪代码）就是如此。不过也不是每次都很容易，如果不能很容易地构建和运行，你可以在完成构建和运行的过程中，认识到代码的高层结构。而且，阅读工作代码，你会非常熟悉如何构建项目。构建通常是复杂的，但是了解构建过程，知道代码是如何变为可执行程序的，会大大加深你的理解。
2. 别死盯细节。读代码要做的第一件事，是找到对代码的结构和风格的感觉。开始应当浏览，并且努力找出各部分代码都在干什么。这样你能熟悉整套代码的高层结构，也会明白你正在看的是什么样的代码（重构良好的，还是乱成一团的）。这时候你要做的就是找到入口（可能是main函数，也可能是servlet，controller之类），看看下面的分支是怎么展开的。这一步不要花太多时间，你对全部代码更熟悉之后，随时可以退回来。
3. 确保理解所有构造（construct)。除非你非常精通这门编程语言，否则多半还有些东西是你不知道的。在概略了解代码的阶段，要记下每一个不熟悉的构造。如果这样的构造有很多，下一步就不言自明了。如果搞不懂代码行为的意义，你什么也干不了。即便你不熟悉的只是少数构造，仔细观察推敲没准也是好事。你可能会找到一些以前不知道的关于这门编程语言的知识，我就很乐意为此花上几个小时。
4. 待熟悉了大多数构造之后，就可以搞几次随机的深入探查了。做法类似第2步，快速浏览代码库，但是这次要随机抽几个函数或者类，一行行地看下去。真正的考验现在才开始，但你的收益也是从这一步开始显现。主旨是：真正深入到你所阅读的整套代码的概念体系（组件结构）当中。这又是一个速度快不起来的步骤，但是在这一步，一定要尝试深入理解若干繁杂的细节。和第2步一样，在这一步，每次你多了解了一些上下文再回头看看，你的理解就更深入一些。
5. 前几步中肯定还有你不明白的地方，现在最合适的就是跑几个测试，看看已有的测试。测试很可能会大大打消你的疑惑，加深你对所测试代码的理解。我时常不能理解，为什么有些开发人员在阅读和理解代码时，忽略严密而精巧的测试套件。当然，也有时候是因为没有测试程序。
6. 如果没有测试程序，这时候就该写上几个。这样做有很多好处，它会加深自己的理解，它可以完善整个代码库，在阅读代码的时候也在写代码，这样对已有代码和你都有好处，你也可以真正动手参与进去。即便有现成的测试程序，为了加深自己的理解，你也可以再写一些。测试人家的代码，一般要求换个角度思考，之前你感到迷惑的概念也会变得更清楚。
7. 把弄不懂的部分拿到单独的程序中来。我发现，读代码时这样做，哪怕只是为了调节阅读的节奏，也是非常有乐趣的。即使你不理解代码的底层细节，也可能会对代码的功能有些高层面的想法。那为什么不把一些功能抽到单独的程序中测试呢？如果只运行一小段程序，debug就容易多了，而且这样的过程反过来又会加深你的理解。
8. 代码很乱（dirty）很糟糕（smelly）？那么重构吧。我可不是建议你把整个代码库推倒重来，但是重构一些部分确实可以让你的理解更上层楼。一开始要做的是把你明白了的功能变为独立的函数。在你真正理解之前，重构之前的函数只是看起来没问题，而重构可以把它们变成你想要的样子。依靠重构，你可以把代码变成自己的，而不要全部重写。好的测试程序可以帮上忙，不过如果你没有，就一边测试一边重构吧，而且只改动那些你确认弄懂了的功能。即便测试看起来太少太不完善，也要相信你自己的开发水平，有时候你只管大胆尝试就好（如果确实需要，总是可以回退(revert)的）。
9. 如果上面说的都不管用，就找个同伴跟你一起读代码。能从读代码中受益的可能并不只有你一个人，所以不妨抓住其他人，一起阅读。不过别找专家，他们给你的解释都是高层面的，这样看代码时注意的那些细节就都被忽略了。如果找不到人一起阅读，你又实在看不懂，有时最好的办法就是问别人。可以问你的同事，如果你在读的代码是开源的，也可以在网上问问其他人。记住，这只是最后的办法，不要一开始就这么做。
如果时间很紧张，短时间内必须弄懂某些代码，上面的步骤中只能选一步，我会选择重构（第8步）。你可能没法明白太多东西，但你肯定可以理解真正动过的部分。无论时间是不是紧张，你要记住的是：如果你第一次接触重要的代码库，肯定不能一下子就看懂，甚至不可能很快看懂。你可能需要耐心读上几天，几周甚至几个月——坦然面对就好。即便有专家坐在你身边，也省不了太多时间（我写的关于教和学的系列文章最后一篇就会谈这个问题）。如果你读（或者写）代码的耐心足够，方法得当，你肯定能成为对项目所有方面都非常熟悉的人，也是大家对代码库有问题时出面解答问题的人。你也可以不阅读代码，选择成为那个总想找人来解释的家伙。我想要做哪样的人，我自己很清楚。
我们都喜欢新写代码，它的诱惑力在于，我们能搞定问题。起码，这次搞不定，下次可以搞定。真相是：你在实践中不断提高，永远不可能一下就彻底搞定。这就是新写代码的价值所在，你在练习，你的水平在提高，但是阅读和改动其他人写的代码也很有价值（至少不亚于自己重新写），从中你学习到的不光是有价值的技术知识，还有关于整个工作领域的知识（毕竟，代码才是文档的最终形式），这种知识通常更有价值。
每一段不遵循传统的，莫测难懂的代码，都是有价值的。你知道我说的是什么，虽然它看起来一团糟，但本意并非如此（也可能因为它是Perl代码:)）。每次我看到这样的代码，我都这么想。不妨把阅读它当作猜谜游戏，想想你能学到什么。是的，这很折磨人，但必须承认，你也希望能动手就能写出这么糟糕的代码。如果你花时间阅读这样的代码，你肯定更可能写出这样的代码——这倒不是说，你一定会写这样的代码，但你肯定希望自己能够。最后要说的是，态度总是非常重要的。如果你把阅读代码看作闲杂事，那它就是闲杂事，而你肯定会逃避，但是如果你把它看成机会，事情就不一样了。
欢迎转载，转载请注明出处。
Founders at Work, Chapter 12
Yurii 翻译
Livingston:你提到，Gmail最开始是“有争议的”，能接着说下去吗？
Buchheit:我觉得，一般来说，人们会不太适应不一样的东西。即使是现在，我谈到给Gmail增加新特性，除非是很小的改动，或是不改变现状，只做些调整，否则大家都不会喜欢。人们对“可能”的理解非常狭隘，相比真正的可能性，对于“可能”，我们的思维有许多局限。所以他们会不适应，他们有点喜欢想尽办法来反对。
但是我个人更钟爱新的东西，所以我总是非常愿意看看会发生的事情。这是我加入Google的最大理由。这理由足够强，强到我确信这是一桩好事：我只是觉得这很有意思，看到将要发生的事情，我很激动。
就这样，Gmail之所以让我激动，也是因为想看看大家会是什么反应。我喜欢某些不确定，因为这有点悬念、有点激动，好像是冒险，对吧？即便没有做成，你也可以从中学到很多。但不是每个人都喜欢冒险。许多人好像就是讨厌不确定。在生活的每个方面都讨厌不确定。
我忽然想起来，某段时间我问大家，如果他们在玩俄罗斯轮盘赌，有一把枪，枪有10亿个弹筒（或者非常多的，也就是说，他们被杀的可能性微乎其微），他们愿意花多少钱玩一盘？许多人都觉得这个问题很不礼貌，他们回答，“给我多少钱我也不玩”。但我们其实每天都在玩这个游戏。他们开车来上班，挣工资，其实一路都是在冒险，但是他们不希望知道自己其实在冒险。他们希望自欺欺人，假装一切都与风险无关。
欢迎转载，转载请注明出处。
Founders at Work, Chapter 12
Yurii 翻译
Livingston： 那时候Google一门心思关注搜索，你有没有担心过自己的项目被抛弃？
Buchheit：一直都是。我还得说，现在看来Gmail很不错，但我们开发是很早时候的事了。Gmail是第一个真正偏离单纯“web搜索”的产品。Groups其实也依赖搜索——只不过它搜索新闻组里公开的帖子。
Livingston：Gmail还必须要邀请才能加入吗？
Buchheit：不用，你可以用手机申请。
Livingston：也可以通过Blogger，对吗？
Buchheit：我们已经向许多不同的方面开放了。大学生可以申请，我们希望开放给学生。
Livingston：为什么要邀请加入，这背后是怎么想的？
Buchheit：理由有好几个。我又得说一遍，邮件的问题很麻烦，不只是在数据规模那些方面。有个问题很重要，那就是，我不希望数据有任何损失，因为没人愿意弄丢邮件。如果web搜索出了问题，你可以退回去，重抓一遍网页，但是邮件不同，一旦丢了就不可挽回。
我非常关心系统的稳定性。策略之一就是控制用户的规模，这样就不会超出限制。你必须时刻确保当前用户享受到优质的服务。同样，这做法也约束了某些滥用email的行为，举例来说，这样发垃圾邮件的人就很难获得1000万个帐户——那样的后果很糟糕。
欢迎转载，转载请注明出处。
Founders at Work, Chapter 12
Yurii 翻译
Livingston：还有哪些新特性是独创的？
Buchheit：对话视图——你打开某个对话，其中的所有邮件会像卡片一样列出来，而不是单独出现。
Livingston：这是你想出来的？
Buchheit：其实有好几个原因。其中之一是，我曾做过Groups，那里同样有归类(threading)。另一个是，我们内部有太多的邮件。
如果没有会话，就会出现这种情况：有人发出了一封邮件，有四个人回复了，五个小时之后还有人在回复，其他人会觉得，“这已经重复谈论过五次了，你还要回复。”
据我们观察，人们费那么大力气管理邮件的原因之一在于，他们尝试把对话归拢到一起。他们把邮件放到同一个文件夹——否则就会忘记，或是放错文件夹，对话就完蛋了，再也没法回复。
大家用各种工具和诀窍来管理会话。为什么不把它们直接归拢到一起呢？后来我们又想到，“我们来把引用他人的邮件内容隐藏起来吧”。因为这样阅读速度更快，而不需要浪费精力。我们同样希望集成IM聊天。做第一版的时候，我们没时间集成那个功能，但是很早的原型中就有聊天功能的，因为我们希望把聊天和email做到一起，这两者是一体的。所以，我们会从聊天的角度来看待email，所以我们给聊天加入email功能，而不是走其他的路。显然，聊天是为谈话服务的——没有人受得了分割成一条条的聊天纪录。所以，谈话视图也是从此而来——有段时间我们甚至把email的格式设定得更像聊天。
欢迎转载，转载请注明出处。
Founders at Work, Chapter 12
Yurii 翻译
Livingston：这么说，你花了一天来做Gmail，而你不知道自己在做的事情的意义——之后呢？
Buchheit：很长时间里就只有我一个人，然后Sanjeef Singh加入进来。但是，在Google更换项目，尤其是那时候的Google更换项目，并不容易。不是说，某一天你就忽然去做一个新的项目了。那时候他正在做企业搜索，所以他还得花很多时间在企业搜索上。过了很久，Sanjeef才把大部分时间用在Gmail上。所以有很长的时间，Gmail的进展非常慢。
开始主要是我，然后是我和Sanjeev，之后另一个家伙Jing Lim也来了。团队的增长非常缓慢。做一个email那样迥然不同于Google传统的东西，这想法人们还是不太确定。
Livingston：你宣布：“这是了不起的东西，我们要发布了”。这是什么时候？
Buchheit：是发布几天以后。这项目很大。有些时候，我们似乎根本不可能完成它。
Founders at Work是一本有意思的书，讲述了若干有意思的创业故事，我看得兴起，顺手把访谈Gmail创始人Paul Buchheit的一章翻译出来，给有兴趣的朋友看看。
欢迎转载，转载请注明出处。
Founders at Work, Chapter 12
Yurii 翻译
Paul Buchheit是Google第23名员工。他创造并领导开发了Google的Web邮件系统，Gmail，该产品引领了当今所谓“Web2.0”的众多特性。除此之外，Buchheit开发了Adsense的第一版原型，Google依靠这个程序在其它网站显示广告。在2000年一次关于公司价值的一次会议上，他提出了现在众所周知的公司信条：不做恶（Don’t be evil）。
尽管Buchheit算不上创始人，但他对Google的贡献，可能比其他许多创始人在创业时的贡献更大。Gmail其实是在Google内部诞生的——这是一个传奇般的项目，起初，它并不是公司的主要业务，只是由一小群人发起，而且，许多人开始并不看好它。
Livingston：讲讲事情的开头吧。Gmail是非正式项目（side project）还是公司指派的任务？
Buchheit：实际上两种因素都有。我很早就在做Email软件，当时大概是1996年，但只是个小项目。但Gmail的想法从来没有实现过。奇怪的是，大概因为一些别的理由，那时候我似乎就想叫它Gmail。这只是凑巧——它并不必然是Gmail的前身，却是我一直在思考的，因为我长久以来就对email不满意。
那时候我在学校念书，还没有hotmail。要看邮件，你得回宿舍。我想，这可真够傻的，我应该能在任何地方检查邮件。所以就想做基于web的邮件。我真的不知道那时候自己在干嘛，因此也没什么结果。我写了点程序，但一直没什么用处，也从来没投入实用。
中间内容就不提了，直接说最后：我到了Google，为Google Groups工作，groups和email不完全一样，但是有关系。等Google Groups的第一代产品差不多完善之后，他们问我，是否愿意开发某种email或是针对个人的产品。这只是一个粗略的意向。他们只是说：“我们觉得这类东西有点意思”。当然，我很高兴干这个。