《Beautiful Code》是由Greg Wilson在2006年构思的，本书的初衷是希望从优秀的软件开发人员和计算机科学家中提炼出一些有价值的思想。他与合作编辑Andy Oram一起走访了世界各地不同技术背景的专家。
虽然本书的涉猎范围很广，但也只能代表一小部分在软件开发这个最令人兴奋的领域所发生的事。还有许多其他的项目同样是有教育意义的，每天都有大量的程序员在不断地推动着这些项目，而我们无法联系到所有的这些程序员。此外，还有许多其他优秀的约稿者没有出现在本书中，因为他们当时都太忙了，或者有着与之冲突的义务。为了汲取所有这些人的思想，我们希望将来沿用相同的方式来编写后续书籍。
本书章节内容的组织
第1章，正则表达式匹配器，作者Brian Kernighan，介绍了对一种语言和一个问题的深入分析以及由此产生的简洁而优雅的解决方案。
第2章，Subversion中的增量编辑器：灵活的接口，作者Karl Fogel，首先介绍了一个精心设计的抽象，然后证明了这种抽象能够在系统将来的开发中带来一致性。
第3章，我从未编写过的最漂亮的代码，作者Jon Bentley，介绍了如何在无需执行函数的情况下测试函数的性能。
第4章，查找，作者Tim Bray，应用了计算机科学中的多种技术来研究一个对许多计算任务来说都很重要的问题。
第5章，正确、优美、迅速（按重要性排序）：从设计XML验证器中学到的经验，作者Elliotte Rusty Harold，解决了程序在完备性和高性能之间的冲突。
第6章，集成测试框架：脆弱之美，作者Michael Feathers，介绍了一个打破常规并获得优雅解决方案的示例。
第7章，漂亮的测试，作者Alberto Savoia，介绍了一种全新的测试方法，不仅能够消除bug，还可以使你成为一个更优秀的程序员。
第8章，图像处理中的即时代码生成，作者Charles Petzold，介绍了一种在维护可移植性的同时还能够提高性能的方法。
第9章，自顶向下的运算符优先级，作者Douglas Crockford，介绍了一种几乎被人们遗忘的解析技术，并且给出了它与JavaScript语言的最新相关性。
第10章，寻求快速的种群计数，作者Henry S. Warren, Jr.，揭示了在一个看似简单的问题上如何应用一些巧妙的算法。
第11章，安全通信：自由的技术，作者Ashish Gulhati，讨论了一个安全消息应用程序的发展过程，这个程序被设计用来使用户能够直观地访问那些成熟但却经常产生误解的密码技术。
第12章，在BioPerl里培育漂亮代码，作者Lincoln Stein，介绍了如何通过将一种灵活的语言和客户定制的模块组合在一起，从而使编程技术一般的开发人员能够为他们的数据创建出功能强大的虚拟化形式。
第13章，基因排序器的设计，作者Jim Kent，将简单的构件组合起来从而为基因研究人员生成稳定并且有价值的工具。
第14章，优雅代码随硬件发展的演化，作者Jack Dongarra和Piotr Luszczek，介绍了LINPACK及其相关主要软件包的发展历史，从而给出了在面对新的计算架构时，应该如何对假设条件进行重新评估。
第15章，漂亮的设计会给你带来长远的益处，作者Adam Kolawa，阐述了数十年前所使用的良好设计原则如何帮助CERN中广泛应用的数学库（LINPACK的前身）经受住时间的考验。
第16章，Linux内核驱动模型：协作的好处，作者Greg Kroah-Hartman，阐述了不同的协作者在解决不同难题上所做出的努力以及如何来推动一个多线程复杂系统的成功发展。
第17章，额外的间接层，作者Diomidis Spinellis，介绍了如何对多数驱动程序和文件模块中的常见操作进行抽象，以及如何通过这种抽象来提升FreeBSD内核的灵活性和可维护性。
第18章，Python的字典类：如何打造全能战士，作者Andrew Kuchling，介绍了一个能够适应某些特殊情况的完备设计以及如何通过这种设计来使一种语言特性支持许多不同的用途。
第19章，NumPy中的多维迭代器，作者Travis E. Oliphant，展示了如何把复杂性成功隐藏在简单接口背后的设计步骤。
第20章，NASA火星漫步者任务中的高可靠企业系统，作者Ronald Mak，介绍了如何使用工业标准、最佳实践和Java技术来满足NASA探险任务的高可靠性需求。
第21章，ERP5：最大可适性的设计，作者Rogerio Atem de Carvalho和Rafael Monnerat，介绍了如何用免费的软件工具和灵活的架构来开发一个功能强大的ERP系统。
第22章，一匙污水，作者Bryan Cantrill，让读者和作者一起来体验一个令人毛骨悚然的bug以及一种违背直觉的巧妙的解决方案。
第23章，MapReduce分布式编程，作者Jeff Dean和Sanjay Ghemawat，描述了一个能够提供简单编程抽象的系统，这种抽象用来在Google中进行大规模分布式数据处理，并能够自动处理分布式计算中的许多难题，包括自动并行化、负载均衡以及故障处理等。
第24章，美丽的并发，作者Simon Peyton Jones，通过软件事务内存（Software Transactional Memory）来消除大多数并发程序中的困难，在本章中使用Haskell语言来说明。
第25章，句法抽象：syntax-case 展开器，作者R. Kent Dybvig，介绍了如何在Scheme中防止宏—这个许多语言和系统中的关键特性—产生错误的输出。
第26章，节省劳动的架构：一个面向对象的网络化软件框架，作者William R. Otte和Douglas C. Schmidt，应用了许多标准的面向对象设计技术，例如模式和框架等，来分发日志，从而保持系统的灵活性和模块性。
第27章，以REST方式集成业务伙伴，作者Andrew Patzer，通过根据需求来设计一个B2B Web Service，从而表现出设计者对程序开发人员的尊重。
第28章，漂亮的调试，作者Andreas Zeller，介绍了如何通过严谨的验证代码方法来减少追踪错误的时间。
第29章，代码如散文，作者Yukihiro Matsumoto，介绍了他在设计Ruby编程语言时所遵循的一些规则，并且这些规则通常均有助于开发出更优秀的软件。
第30章，当你与世界的联系只有一个按钮时，作者Arun Mehta，介绍了在文字编辑系统中一种不可思议的界面设计，这种设计使患有高度运动神经残疾的用户，例如Stephen Hawking教授，也可以通过计算机进行交流。
第31章，Emacspeak：全功能音频桌面，作者T. V. Raman，介绍了如何在Emacs通过Lisp的advice功能来满足Emacs整体操作环境中的需求 —— 产生丰富的语音输出，而同时无需修改软件系统的底层源代码。
第32章，变动的代码，作者Laura Wingerd和Christopher Seiwald，列出了一些对编程精确性有着强大影响的简单规则。
第33章，为“The Book”编写程序，作者Brian Hayes，介绍了在解决一个看似简单的计算几何学问题时所遭受的挫折，并给出了这个问题令人惊叹的解决方案。
字体约定
本书使用如下印刷惯例:
斜体（Italic）
表示新的术语，数学变量，URL，文件名和目录名，以及命令。
等宽字（Constant width）
表示程序代码，文件内容，在计算机控制台上的文本输出显示。
等宽粗体字（Constant width bold）
表示用户手工输入的命令或其他文本。
等宽斜体（Constant width italic）
表示需要使用用户提供的值来代替的文本。
怎样联系我们
请将您对本书的宝贵意见及问题告诉我们。来信请寄：
美国：
O’eilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
100080北京市西城区南大街2号成铭大厦C-807，邮编：100035
奥莱理软件（北京）有限公司
我们为本书设有一个Web页面，上面列出了勘误、例子和一些额外的信息。你可以通过如下网址访问该页面：
http://www.oreilly.com/catalog/9780596510046
对本书评论或者提技术问题请发送email到：
bookquestions@oreilly.com
info@mail.oreilly.com.cn
关于我们的书籍、研讨会、资源中心以及O'Reilly Network更多的信息，请参考网站：
http://www.oreilly.com
http://www.oreilly.com.cn
代码示例的使用
本书可以帮助你完成日常工作。你可以在你的程序和文档中使用书中的代码。除非你需要重用大部分的代码，否则就不需要联系我们获得许可。例如，如果在编写程序时使用了书中的几段代码，那么不需要申请许可。而在销售或者分发O'Reilly书籍中的光盘示例代码时则需要获得许可。
引用本书内容或者示例代码来回答问题无需获得许可。而把书中的大量示例代码写入到你的文档中则需要获得许可。
我们欢迎，但并不要求，授权。授权通常包括标题、作者、出版商以及ISBN。例如：“Beautiful Code, edited by Andy Oram and Greg Wilson. Copyright 2007 O'Reilly Media, Inc., 978-0-596-51004-6.”
如果你认为你对代码示例的使用方式不符合上面给出的情况，请联系我们permissions@oreilly.com。
Gary Wilson：暂无简介
聂雪军：2002年起从事软件开发工作，主要开发语言为C++，具有较丰富的Windows和Linux开发经验。译作有《C++编程风格》、《Exceptional C++中文版》等。
译者序一
这是一本什么书
刘未鹏(pongba)
C++的罗浮宫(http://blog.csdn.net/pongba)
这是一本独特的书。
其英文封面上本应写着作者的位置写的却是“Edited by Andy Oram and Greg Wilson”。Edited？！那作者呢？
实际上，这本书有38位作者！
现在你知道为什么封面上不列作者了吧？一，列不下。二，也是更重要的，每位作者都是某个领域的大牛，怎么排列？
38位作者共贡献了33章内容。这种做法带来了三个重要的结果：
?每位作者都是大牛，所以每个人都知道自己在说什么，绝无一个人写整本书而导致的在某些不甚在行的地方语焉不详的情况。
?每位作者都将自己心目中对于“代码之美”的认识浓缩在一章之中，张力十足。
?心理学上有一种说法叫做联合评估与单独评估，即如果你单独评估一样东西，是难以把握其好坏的，然而如果将它跟同类东西比较一下，就能够作出更准确的判断。38位大牛，每个人对代码之美都有自己独特的认识，现在将其一览无余的放在一起，对于热爱程序的每个人都不啻一场盛宴。
当初朋友介绍这本书给我的时候，我顿时产生了一种恍然大悟的感觉：这才是我真正想读的书的样子啊，技术书籍本来不就应该是这个样子的吗？就一个主题，让几十位领域大牛各抒己见，完美符合了我内心对“书”的定义。
编程是计算机行业的核心活动，而代码则是编程活动的核心，代码之美一直以来都是一个永恒而玄妙的话题，如果让我选一个主题来请教这些作者，我还真想不出比这更好的主题！
所以，我就迫不及待地把这本书介绍给了更多的朋友。
所以，我同样也迫不及待地想要告诉你，这本书的作者都有哪些牛人了：
Jon Bentley：久负盛名的《Programming Pearls》（《编程珠玑》）的作者。在斯坦福获得学士学位，在北卡罗莱纳获得硕士和博士学位。继而在卡内基梅隆执教6年。贝尔实验室前研究员，西点军校和普林斯顿的访问教授。
Brian Kernighan：C语言圣经K&R C（《C程序设计语言》）和《程序设计实践》两本不朽著作的作者，他的书被翻译成近30种不同的语言。
Charles Petzold：经典的《Windows程序设计》影响了整整一代程序员，被奉为Windows编程圣经。而他的另一本经典著作《编码的奥秘》则另辟蹊径，由浅入深地将计算机最深层的奥秘娓娓道来。
Tim Bray：XML创始人之一。
Yukihiro Matsumoto：Ruby之父。
Douglas C. Schmidt：著名的C++跨平台开源框架ACE的设计者，《C++网络编程》卷I，卷II的作者。
Jeff Dean：天才架构师，Google大型并发编程框架Map/Reduce作者。
Diomidis Spinellis：两届Jolt大奖得主，分别以《Code Reading》和《Code Quality》获2004 和2007年的Jolt大奖。
Simon Peyton Jones：Haskell语言核心人物之一，并领导设计了著名的Haskell编译器GHC。
Douglas Crockford：JSON发明者，JavaScript领域大牛，写了广为流传的《JavaScript，世界上最被误解的语言》。
Bryan Cantrill：著名的DTrace的作者之一；之前是Sun的杰出工程师，主要工作领域为Solaris内核开发……
Greg Kroah-Hartman：目前的Linux内核维护者，经典的《Linux Device Drivers》的作者。
Andreas Zeller：大名鼎鼎的GNU DDD可视化调试器的作者，著作《Why Programs Fail》获得2006年Jolt生产效率大奖。
Sanjay Ghemawat：大规模分布式文件系统Google FileSystem（GFS）的主要作者（GFS是Google的基石之一），同时也是Google Map/Reduce以及Google BigTable的作者之一。
……
（完整的作者列表见于封底）
如今这些如雷贯耳的名字居然出现在同一本书中，怎能不令人兴奋！
你是程序员吗？你对代码之美的认识是什么？你想知道牛人们对代码之美是怎么想的吗？
其实，这本书最奇妙的地方还不止于这一点，而在于，如果你知道这些作者的名字，你肯定会忍不住去看一看。如果你不知道这些作者的名字，你更加会忍不住去看一看。因为你知道这些人的观点肯定不会让你失望！
最后，还有一个更大的好消息， Oreilly出版社表示还会继续出第2版，到时会邀请更多的牛人！
另外我们的翻译团队也很“漂亮”，团队组建的过程也很是有趣，在此就留一个悬念，稍后会公布:-)
注：由于我只是译者之一（我们的翻译团队里面有一堆牛人），所以这篇序仅代表我个人意见:-)
译者序二
解读未鹏留下的“悬念”
聂雪军
去年8月份，我正在为自己的第一篇国际会议论文热身，机械工业出版社华章分社的 陈冀康先生把《Beautiful Code》的电子版发给我，问我能否接下这本书的翻译工作。在粗略阅读之后，我的第一个感觉就是这本书绝对是一本“重量级”的好书，这一点从各个章节作者的名气就可以看出来，未鹏在之前已经解释得比较清楚了。第二个感觉就是这本书凭借个人力量是难以完成的，书中的每一章节都涉及某个领域中较深的研究主题，如果没有相关的知识，很难把作者意图完整无误地表达出来。于是，我建议冀康征集一些有实力的译者或者有经验的开发人员，组成一个团队来完成这本书的翻译工作。
然而，团队的组建并不顺利。冀康在一些比较知名的论坛上发布了征求译者的信息，但响应者不多，而我能够找到的合适人选也只有老同学王昕。正当我犹豫着如何把翻译工作继续进行下去时，事情出现了转机。未鹏在看到征集译者的帖子后提出加入翻译团队，我们在MSN上一起讨论起如何开展这本书的翻译工作。我们都认为这本书确实是一本难得的好书，建议在翻译团队中再增加一些有实力的人。于是，我们趁热打铁把自己熟悉的一些同学和同事都拉进MSN聊天室里，然后动员他们再推荐一些合适的译者。
事实证明，群众的力量是巨大的。当天讨论的结果很成功，我们最终组成了一个翻译团队，取名为“BC Group”，其中的BC即为“Beautiful Code”的缩写。我们根据每个人的技术专长和感兴趣领域来分配翻译任务，并且为了保证翻译风格的一致性，我们规定了在译稿中要统一专业术语，叙述语态要保持中文习惯等。在随后的翻译过程中，我们创建了Google Group专用论坛，定期地在MSN上讨论所遇到的问题，交流翻译过程的体会和心得。功夫不负有心人，在经历半年多的努力之后，本书的中文初稿终于得以完成。
然而，或许是好事多磨，《代码之美》在出版过程中遇到了一些波折。本来计划4月份左右出版的《代码之美》，不得不一直推迟到9月份才确定下来。所幸的是，问题最终得以解决，而BC Group的努力也没有付之东流，因此不久之后本书将与读者见面。
当然，由于时间和精力有限，书中难免会存在一些问题，还望各位读者不吝指正。
致谢
感谢BC Group所有成员的努力。感谢史晓明积极参与翻译工作的讨论。感谢机械工业出版社华章分社的编辑，以及所有为本书付出努力的人们。
2008年9月于武汉
附BC Group成员简介：
王昕：易安信（EMC）中国研发中心高级程序员，感兴趣的技术领域：运用不同的编程技术，搭建大型的、可扩展的、高性能应用程序。译有《C++ STL中文版》，《C++编程惯用法》等。
刘未鹏：南京大学计算机系硕士在读，热爱编程、数学、心理学。个人博客“C++的罗浮宫”（http://blog.csdn.net/pongba），长期关注C++前沿技术。译有《Imperfect C++中文版》、《Exceptional C++ Style中文版》、《修改代码的艺术》等。
袁泳：高级程序员，一直从事IBM WebShere Commerce的开发工作。
王江平：运软网络科技（上海）有限公司高级软件工程师。技术专长为C++，酷喜读书，曾长期从事EDA领域行业应用软件开发，目前的主要工作是Windows系统监控。
史苏：欧特克中国软件研发中心软件开发工程师，主要负责建筑CAD软件相关的研发工作。热衷于C++，算法，数学，程序设计语言理论和社会化网络方面的研究。酷爱读书，参与翻译《游戏编程精粹6》。
华咤镇： 2006年加入微软开发工具部中国分部，目前从事微软并行处理平台的研发工作。此前曾参与Visual Studio中WCF模块的开发工作。此前在FujiXerox工作了3年，从事打印机管理软件和文档处理工具的开发。
朱永泰： 2007年加入微软服务器与开发工具部中国分部，目前在develop devision从事CLR的相关工作。
聂雪军：华中科技大学计算机学院博士在读，研究方向为存储网络。感兴趣的技术领域包括C++，并行算法，大型软件的协作开发等。译有《Windows编程启示录》，《Exceptional C++中文版》，《C++编程风格》等。
《程序员》杂志技术主编 孟岩
《代码之美》已经成为经典。关于它本身的赞美之辞已经不少了，不过到底从这本书里该读些什么，我倒是有些思考。
20世纪90年代初期，当时正在加州大学埃尔文分校攻读博士学位的Douglas Schmidt在观察了他所参与的软件项目开发实践之后，得出一个结论，即未来的软件开发将越来越多地体现为整合（integration），而不是传统意义上的编程（programming）。换言之，被称为 “软件开发者” 的这个人群，将越来越明显地分化：一部分人开发核心构件和基础平台，而更多地人将主要是配置和整合现有构件以满足客户的需求，类似现代汽车、机床和家用电器制造业的产业格局即将到来。面对这一前景，博士生Schmidt一方面写文章对于其进步意义大加赞扬，另一方面毫不犹豫地投入到核心构件及平台的开发阵营中去。他很清楚，在这样一种分工体系中，由于软件整合产业很难出现垄断局面，因此大多数利润总是被截留在上游，人当然要往高处走，整合化是好事，但他老兄宁可让别人来推动这个好事。
事实上，软件产业中大多数预测都被历史的发展无情地抛到垃圾堆里了，然而Schmidt博士生的这个预测却惊人的准确，其后十几年软件的发展完美地印证了他当年的判断。因此，他本人基于这一预测所选择的人生道路也一帆风顺。如今已经是教授的Douglas Schmidt先后创造了ACE、TAO、CIAO等一系列分布式计算基础件，先后主导了美国学界和国防领域内若干重大科研与实际开发项目，成为世人公认的分布式计算架构领导者。
抛开他个人的辉煌不说，“整合化”趋势实际上已经深刻地改变了世界软件工业的面貌，从而也影响了身为晚进者的我们的命运。如今大部分的程序员实际上是在整合与配置现有资源以满足需求，而不是真正意义上的“编程”。这当然是一件好事，整合同样需要深刻的洞察力和创新精神，优秀的整合者与天才的程序员一样不可多得，甚至更加罕见。然而我们也不能不承认，大多数整合性的工作是机械的，简单的，重复的，欠缺创意的，深入的思考往往不必要。因此，在这个整合为王的时代里，思考的精神在钝化。更有甚者，互联网和搜索引擎的出现大大加速了这种钝化，几乎所有的问题都有人解决并且张贴在互联网上了，因此独自思考和解决问题已经成了不必要的、降低效率的行为，不但不时髦，而且不经济。软件开发迅速成为一个强调搜索和短期记忆力的技能，我想这是50年前第一代程序员们做梦也没有想到的。
老实讲，就整体而言，我仍然认为这是一种进步。任何一个产业的成熟，无不伴随着分工的明晰、技能的简化和从业门槛的降低。与少数人享受思考乐趣的需求相比，大多数人享受便宜而无处不在的软件服务的需求显然远为重要。但是，对于身处软件行业中的个体来说，思考力的削弱和丧失却是不折不扣的悲剧。这一点不必过多解释，几年来苦苦寻找自己核心竞争力的开发者们都知道我说的是什么意思。长期以来对中国开发者社群的近距离观察使我确信，尽管作为一个产业，中国软件一直享受着比较快的成长，但是总体而言，中国的软件开发者越来越迷惘、焦躁和不自信。这一情况当然是由多种原因导致的，但开发者们每念及此，多抱怨体制、产业、市场等身外之物，实在也有失偏颇。平心而论，这几年中国软件技术界的生存环境还是有了很大改善，对于那些真正出类拔萃的程序员来说，过上一种充实自信的生活并不困难。摆在每一个个体面前的主要问题还是在于能否出类拔萃，而这就需要我们重新找回思考的能力。具备强悍思考能力的人，也就具备强悍的解决问题的能力，而这样的开发者永远都是产业中的稀缺资源。
我认为这正是《代码之美》这本书的一个重要价值。合作的诸位大师级作者，给我们一个很好的机会，让我们能够一边阅读，一边思考，找回深思熟虑的智慧火花。这本书里所讲的每一个问题，可以说都是程序员在工作中会遇到或者至少会擦边的问题，既没有故弄玄虚的文字游戏，也没有携带了领域知识的私货，只有朴实而实际的一个个问题。虽然不是以提问的方式给出，但在整个阅读的过程中，我们还是能够找到很多机会与大师互动，不断地发现问题和解决问题。我在阅读中经常感到，看上去一个很简单的问题，却被这些大师们一层一层挖掘得如此深入，到最后阶段不由得令人感到战栗和震撼。看着这些智慧的光芒，我们不但可以领略大师之所以称为大师的秘密，而且也认识到思考的真谛。因此，千万不要像看小说一样一带而过，那样会错过本书95%的价值！我们不是要阅读这些文字，而是要与文字背后的大师交流学习，一点一点把自己的心得记下来，对于作者提出的新问题，先自己思考，直接写程序尝试，争取跟上大师的思路，甚至可能需要反复几遍，才能真正读通这本书。这样的精力不会是白费的，读者应当认识到，当我们拥有这本书的时候，我们获得了怎样宝贵的机会，可以在相对比较短的时间里有效地提升自己的思考能力。这是一个机会，也是一次考验，我绝对相信，通过了这次考验的读者，会在思考和解决问题的能力上有一个大的进步。
我希望自己能够以这样的态度读这本了不起的书，以此文与其他读者朋友共勉之。
推荐序二
编程的艺术
CSDN 副总经理
《梦断代码》译者
韩磊
学术界有一种叫“论文集”的东西，她把许多人的论文整合到一起出版，让读者能够在一本书的篇幅之内，了解某个特定领域的研究状况，是有效的知识传播手段之一。技术界，类似的出版物却是凤毛麟角，的确是一种遗憾！
《代码之美》就是这样一本书。她将38位大牛人的技术文章汇集到一起，讲述作者们认为“最漂亮的代码”，其涉及应用领域虽广，而代码之美却一以贯之。如果我们承认编程是一门艺术—具有高度创造性和人类智慧参与的活动，不是艺术是什么？—那么，这33篇文章恰恰体现了这门艺术的最高境界。
别担心！大牛们可不是坐而论道，也没有写什么常人不可索解的奥义，文章主题之朴实无华，比如“查找”，比如“分布式编程”，比如“Linux内核驱动模型”……几乎要让人以为是不知道什么人编写的大学教材呢。这貌似普通的三个主题，作者分别是XML创始人之一Tim Bray、Google Map/Reduce架构发明人Jeff Dean和Linux内核维护者Greg Kroah-Hartman—吓死人的阵容。其余文章也都类似，小题目中见大手笔。
我深信这帮大牛接受约稿、写这种“小”文章，的确是出于对编程的热爱，出于对“漂亮代码”的不懈追求。所谓“漂亮代码”，意思远超“规范、好看”，更多地体现出逻辑、思路与架构。一万块最漂亮砖头堆出来的，不一定是大厦。建筑师在建造大厦之前，胸中早有蓝图在。《代码之美》正展现了38位最优秀建筑师胸中的蓝图。
这本书能出中文版，是中国程序员的福音，其中的每篇文章，都值得读者细细咀嚼、回味。我已经迫不及待地想要看到正式印刷的版本了。
推荐序三
享受代码之美
Thought Works中国咨询师
《重构》译者
熊节
“希望写出漂亮代码的开发者可以向艺术家们学习一些东西。画家常常放下手中的画笔，然后远离画布一段距离，围着它转一转，翘起脑袋，斜着看看，再从不同的角度看看，在不同的光线下看看。在寻求美的过程中，他们需要设计这样一些视角并使它们融为一体。如果你的画布是个集成开发环境（IDE），而你的媒介就是代码，想一想，你如何做到离开画布一段距离，用挑剔的眼光从不同的视角来审视你的作品？─这将使你成为一个更优秀的程序员，并帮你写出漂亮的代码。”
写这段话的Alberto Savoia在他的文章里真的没有讲什么令人敬畏的高新技术或是大架构，他讲的是每个计算机系的大二学生都熟悉的二分查找。所以Savoia真的是在讲如何写出漂亮的代码，所以才选择了这么一个所有人都清楚得不能再清楚的例子。你会觉得这种事情都是些不谙世事的小程序员才会热衷于干的吧？可这位Savoia却是从Google离职以后开创了Agitar Software公司（http://www.agitar.com/）的不折不扣的创业者。有意思吗？一个胡须花白、在这个行业里厮混了数十年、拥有自己公司的老者，还在乐此不疲地谈论“漂亮的代码”。
《代码之美》就是由33篇像这样有意思的文章组成的。像Brian Kernighan、Tim Bray、Charles Petzold、Douglas Schmidt、Yukihiro Matsumoto这样的名字，你甚至很难想象他们会同时出现在同一本书上。或许也只有“漂亮的代码”这样的话题才能激起他们共同的兴趣。于是就有了这本了不起的书：从正则表达式匹配器到图像处理，从通信到基因排序，这些世界上最优秀的程序员毫不吝啬地向读者展示：不论面对什么问题、使用什么语言，代码的美感都是始终存在的，而且这种美感应该是程序员毕其一生不懈追寻的。
作为《重构》的译者，不时有人会问我一些关于重构的问题，其中一个问题让我最感为难：为什么要这样做？真的，如果不是要修改代码，也不是要添加功能，为什么要把这段代码抽取出来呢？让每个方法都保持5行以内的长度到底有什么好处呢？这种时候与其说是有什么利弊权衡，毋宁说就是为了让代码“更漂亮”。当然了，在大部分时间里，软件开发是一项集合了科学、工程和服务的工作，但至少在我们的内心深处─它多少还有那么一点艺术的成分。除了完成任务以外让自己手上的代码更具美感，也算是对自己作为程序员梦想的小小坚持吧。
所以，既然你已经拿起了这本书，就暂时放开那些功利的目标吧─别误会，这可不是一本没用的书，通过阅读这些“大师”们的编程心得，对自己的能力提升就算不能立竿见影至少也有潜移默化之效。但那也只是装珍珠的盒子而已。在一个安静的周末，给自己泡上一杯清茶，跟着38位顶尖高手畅游在代码世界，在他们的指引下赏遍代码之美，这才是作为一个程序员最大的享受呢。
推荐序四
不仅仅是代码
InfoQ中文站总编辑
http://www.infoq.com/cn
霍泰稳
在翻阅完机械工业出版社华章分社快递给我的厚厚初稿后，我不由自主地赞叹“不仅仅是代码”。掩卷沉思，深感本书带给人的震撼远非一个序言所能概括。让我们先来简单看几个这本震撼之作的震撼作者们：
Tim Bray，1995年启动了最早的公共网页搜索引擎之一，1996至1999年间与他人共同发明了XML 1.0；
Bryan Cantrill，《华尔街日报》2006年度最高创新奖获奖产品DTrace的作者之一；
Douglas Crockford，JSON数据格式的发明者；
Jeff Dean，Google网页抓取、索引、查询服务以及广告系统的主力开发者；
Yvkihiro “Matz”，Ruby语言的发明者；
Sanjay Ghemawat，Google Fellow，设计并实现了Google的分布式存储系统、文本索引系统及性能分析工具等；
……
太多了，一句话，都是牛人。想一想，在你的编程生涯中有那么多牛人给你传道授业解惑，那是一种什么样的感觉？是不是在为没有早些看到此书而遗憾，又或为今日能读到此书而庆幸？无论如何，我的感觉是这样的。
但如果你认为此书仅是对代码片段的解剖，并分析哪个算法最美而已，那可是大大低估了这本书的价值，同时也误解了编辑的初衷。在Ronald Mak介绍NASA火星漫步者任务中的高可靠企业系统时，他总结说，与小型程序不同的是，大型应用程序的漂亮性并不一定只存在于优美的算法中。对于NASA的协同信息系统CIP来说，漂亮性在于的它的面向服务架构实现以及大量简单却经过仔细挑选的组件。而本书的策划编辑Greg Wilson在整理书稿的过程中，也体味到在不同的地方我们可以看到代码不同的漂亮性，有些漂亮性存在于手工精心打造软件的细微之处，这儿可以理解为代码段，而另外有些漂亮性则蕴藏在大局之中─那些使程序能够持续发展的架构，或者用来构造程序的技术。也就是说，本书不仅剖析了如何撰写美丽的代码片段，还告诉你如何设计美丽的架构。
那么除了美丽的代码、算法以及架构外，还有其他地方能体现代码的漂亮性吗？现在人们对软件开发行业的关注或者尊崇已经大不如从前，程序员也从以前的高薪一族沦为“软件蓝领”或者“IT民工”，伴随而来更严重的变化是编程的神圣感也在逐步缺失。当一份工作在我们的眼中只是一个糊口的工具时，你很难投之于激情和梦想，更谈不上最后会取得什么成就。让我们看一下大名鼎鼎的互联网隐私服务Neomailbox的首席开发人员Ashish Gulhati对“程序员”是如何定义的吧：作为代码的编写者，在很大程度上是程序员的责任感使得我们编写的代码不仅在设计和实现上是漂亮的，同时还使代码所带来的结果在社会的环境中是漂亮的。这就是我认为自由的代码非常优美的原因。它把计算机技术置于一个最庄严神圣的用途：保护人权和人的生命。
我无意成为一个高尚道德的说教者，只是在本书阅读过程中，逐渐认识到：会编写优秀的代码，会设计优秀的架构，有敢于担当的社会责任心，是一件多么令人骄傲和让人尊敬的事情。
推荐序五
等度的流明
知名技术专家
《大道至简》作者
周爱民
一
我上一次印象深刻的美的体验，大概已经是在十年之前了，那只是在午后睡醒，面对窗外的一棵大梧桐树时的感觉。不过这并不是说我这十年来都只看到了丑的事物，而是说我已经忘了去观察既已存在的美。
直到我拿到这本《代码之美》，我忽然地回到了那种仰望着星光闪烁的夜空，或低头沉思于一两句大家文字的日子里。那时我既不是在思考，也不是在分析，更不是在解释，而只是在感受自然的、文字的，或将自然蕴于文字之中的美。
二
有一本书开启了一个时代，我们如今仍然在这个时代之中而不知觉于这本书的深远影响，那是三位图灵奖得主合著的《结构程序设计》（注1）。其中Dijkstra将人“理解一个程序的种种思维方法”归为三种：枚举、数学归纳和抽象。
显然Wirth先生更为深层地看到了程序的本质，他说“程序＝算法+数据结构”（注2）。他揭示了这样一个事实：一个未知的、无序的世界是不可能实现“程序”的，于是我们抽象它——使它成为结构，或者对象，或者网，或者某个相对规则的事物。然后，我们再着之以“算法”。
《代码之美》这本书，38位大师，在33章的内容中详细讨论了代码中抽象的过程、算法的过程和编程的过程。显然地，这些正是程序中最深刻的美，如同花之蕊，叶之脉，以及维系花蕊叶脉的美的那些汁液。这种对美的触及，使他在我面前闪耀着与前两本书等度的流明。
三
“只有在不仅没有任何功能可以添加，而且也没有任何功能可以删除的情况下，设计师才能够认为自己的工作已臻完美。”（注3）然而编程的过程呢？我们最初只是想实现一个功能。但为了实现它，我们写了一段功能代码、一段测试代码、一段功能代码的配置代码，一段功能代码的配置代码的测试代码……
如此往复不休。
我们回到原始的问题，原本只是要做一个“实现某项功能”的代码，我们却为何把代码做到了“往复不休”的绝境？
或者你做的事情并不完美，但是你应该知道所谓完美的终极。代码要不停的测试，以及为测试代码再写测试代码，这一过程也不是美的。或许你认为它“必须”，但你应知道它终究不美。
四
大师们也并没有创造完美的能力，他们只是在一步步地进行着。在这本书里，Adam Kolawa告诉你的，Lincoln Stein告诉你的，以及Elliotte Rusty Harold等告诉你的，就是那经年累月地或亦步亦趋地进行过程，和那个“终极完美”的定义。
这只是过程和隐于过程中对美的追求。而“美”是什么，还是在你的心底。你心中原本就没有美的感受，如何写得出美的代码？所以代码写到烂处，写到心胸滞涩处，便不如寻一清静所在，捧《代码之美》一册，回顾一下，品味一下，吐故纳新一下了。
看得多远，取决于你站得多高；要想成为他们，你得先知道他们。
这就是我的建议了。
推荐序六
向大师学习美
UMLChina首席专家
WWW.UMLChina.com
潘加宇
我1989年参加高考时，总分120分的语文才考了71分，这最弱一环差点造成致命打击。当时，我最害怕的是写作文，记得当年的题目是写一封信，在右江盆地高温的教室里，我写得汗都滴在试卷上。没想到，后来看的东西多了，“不会作诗也会吟”了，而且居然也能接到杂志和出版社的约稿，写一些文章和序言之类。
翻开本书第29章，Ruby之父Yukihiro Matsumoto（松本行弘）说：Treating Code As an Essay。写代码如同写文章一般，多看多研究大师的作品，才能够信手拈来，写出美丽的代码。本书就是33位大师的倾情之作。
本书并不限定于讨论某一种语言的技巧，你能看到大师们使用现在流行的Java、Ruby，也能看到历史悠久的Fortran。讨论的领域从Linux内核，到NASA火星探测器、ERP系统，让我们从不同角度来体会代码之美。
美除了让人欣赏，还能带来金钱。因北京奥运的成功，博尔特的速度之美估计价值上千万美元。美丽的软件也一样。一些软件公司，公司人少且稳定，多年来专注于做某一个小领域里的软件，对软件的打磨可谓是精雕细琢，美丽软件带来的利润自然也很可观。比起那些靠低人力成本、低价格在市场上打拼的“程序员民工”公司，他们要活得滋润得多，安全得多。
美还可以作装饰。就算没时间看，也可以买一本装点一下。书架上的《人月神话》、《计算机程序设计艺术》摆设了好些年，该换一本《代码之美》了。
推荐序七
探索代码之美
哲思自由软件社区创始人
http://www.zeuux.org
徐继哲
想要向世人展示源代码之美，毫无疑问，大家都需要能够获得源代码，否则一切无从谈起。这让我很自然地想到了发轫于1983年的自由软件运动。自由软件运动认为软件应该是自由的，每个人都具有运行、学习、修改和再发行软件的自由。25年过去了，这一切已经成为现实。《代码之美》的许多章节就是在讨论那些被广泛使用的自由软件，涵盖了操作系统、计算机语言、开发工具和企业软件等领域。
在自由软件运动中发展起来的对称版权（copyleft）思想和GNU GPL软件许可证等从法律层面保证了一个自由软件可以继续自由下去，保证了每一个人都可以获得自由软件，当然也包括源代码。但如何看待软件和源代码仍然是一个关键问题。在主流（技术）媒体上整天讨论“IT民工”和“软件蓝领”的今天，能从美学的角度来思考软件和源代码，对于整个行业来说，实在是幸运之举。
凡高创作的《向日葵》和Richard Stallman创作的GNU Emacs有什么区别呢？一个是没有替代品的艺术品，一个是有着无数替代品的（软件）工具，这就是区别。但进一步思考，我们不难发现：“正如一个独一无二的艺术品的创作过程充斥着大量的技术细节一样，在创作一个可替代的（软件）工具的过程中，作者也付出了独一无二的智慧。”所以，当我们在挖掘软件之美的时候，绝不能像欣赏艺术品那样站在外面，而是要深入其内部—源代码，去学习、体会、修改和赞美。艺术之美存于结果和外在；软件之美存于过程和内在。
但将38位技术精英的智慧汇集到一本书里是不是一个好主意呢？《代码之美》一书勇敢地做了这个尝试。在我阅读过程中，沮丧、无奈和激情交替出现。从技术层面看，此书的内容跨度非常之大，沮丧和无奈在所难免。但当看到如此多的技术精英投入到各自的领域去研究、探索和实践，不由得心潮澎湃，这和我的内心世界产生了共鸣。
从美学的角度去阅读此书吧，她将唤醒你的激情，一种成为真正的黑客（hacker）所必备的激情！
Happy hacking!
推荐序 VI
译者序 XXI
序 1
前言 3
第1章 正则表达式匹配器 9
编程实践 10
实现 11
讨论 12
其他的方法 14
构建 15
结论 17
第2章 Subversion中的增量编辑器：灵活的接口 19
版本控制与目录树的转换 20
表达目录树的差异 24
增量编辑器接口 25
但这是艺术吗 30
像体育比赛一样抽象 32
结论 35
第3章 我从未编写过的最漂亮的代码 37
我编写过的最漂亮的代码 38
事半功倍 39
观点 45
本章的中心思想是什么 47
结论 48
致谢 49
第4章 查找 51
耗时 51
问题：数据 52
问题：时间，人物，以及对象 61
大规模尺度的搜索 67
结论 69
第5章 正确、优美、迅速(按重要性排序)：从设计XML验证器中学到的经验 71
XML验证器的作用 71
问题所在 72
版本1：简单的实现 74
版本2：模拟BNF语法 — 复杂度O(N) 75
版本3：第一个复杂度O(log N)的优化 77
版本4：第二次优化：避免重复验证 78
版本5：第三次优化：复杂度 O(1) 80
版本 6：第四次优化：缓存 84
从故事中学到的 86
第6章 集成测试框架：脆弱之美 87
三个类搞定一个验收测试框架 88
框架设计的挑战 90
开放式框架 92
一个HTML解析器可以简单到什么程度 93
结论 96
第7章 漂亮的测试 99
讨厌的二分查找 101
JUnit简介 103
将二分查找进行到底 105
结论 118
第8章 图像处理中的即时代码生成 121
第9章 自顶向下的运算符优先级 145
JavaScript 146
符号表 147
语素 148
优先级 150
表达式 150
中置运算符 151
前置运算符 153
赋值运算符 154
常数 154
Scope 155
语句 157
函数 160
数组和对象字面量 161
要做和要思考的事 162
第10章 寻求快速的种群计数 163
基本方法 164
分治法 165
其他方法 167
两个字种群计数的和与差 169
两个字的种群计数比较 169
数组中的1位种群计数 170
应用 175
第11章 安全通信：自由的技术 179
项目启动之前 180
剖析安全通信的复杂性 181
可用性是关键要素 183
基础 186
测试集 190
功能原型 191
清理，插入，继续…… 191
在喜马拉雅山的开发工作 195
看不到的改动 201
速度确实重要 203
人权中的通信隐私 203
程序员与文明 204
第12章 在BioPerl里培育漂亮代码 207
BioPerl和Bio::Graphics模块 207
Bio::Graphics的设计流程 211
扩展Bio::Graphics 230
结论和教训 234
第13章 基因排序器的设计 237
基因排序器的用户界面 238
通过Web跟用户保持对话 239
多态的威力 241
滤除无关的基因 244
大规模美丽代码理论 245
结论 248
第14章 优雅代码随硬件发展的演化 251
计算机体系结构对矩阵算法的影响 252
一种基于分解的方法 253
一个简单版本 255
LINPACK库中的DGEFA子程序 257
LAPACK DGETRF 259
递归LU 262
ScaLAPACK PDGETRF 265
针对多核系统的多线程设计 269
误差分析与操作计数浅析 272
未来的研究方向 273
进一步阅读 273
第15章 漂亮的设计会给你带来长远的益处 275
对于漂亮代码的个人看法 275
对于CERN库的介绍 276
外在美 277
内在美 283
结论 289
第16章 Linux内核驱动模型：协作的好处 291
简单的开始 292
进一步简化 297
扩展到上千台设备 300
小对象的松散结合 301
第17章 额外的间接层 303
从直接代码操作到通过函数指针操作 304
从函数参数到参数指针 305
从文件系统到文件系统层 310
从代码到DSL（Domain-Specific Language） 312
复用与分离 314
分层是永恒之道吗 315
第18章 Python的字典类：如何打造全能战士 317
字典类的内部实现 319
特殊调校 321
冲突处理 322
调整大小 323
迭代和动态变化 325
结论 325
致谢 326
第19章 NumPy中的多维迭代器 327
N维数组操作中的关键挑战 328
N维数组的内存模型 329
NumPy迭代器的起源 331
迭代器的设计 331
迭代器的接口 337
迭代器的使用 339
结论 342
第20章 NASA火星漫步者任务中的高可靠企业系统 345
任务与CIP 346
任务需求 347
系统架构 348
案例分析：流服务 351
可靠性 355
稳定性 362
结论 364
第21章 ERP5：最大可适性的设计 367
ERP的总体目标 368
ERP5 368
Zope基础平台 370
ERP5 Project中的概念 374
编码实现ERP5 Project 375
结论 379
第22章 一匙污水 381
第23章 MapReduce分布式编程 397
激动人心的示例 397
MapReduce编程模型 400
其他MapReduce示例 401
分布式MapReduce的一种实现 403
模型扩展 406
结论 407
进一步阅读 407
致谢 408
附录：单词计数解决方案 408
第24章 美丽的并发 411
一个简单的例子：银行账户 412
软件事务内存 415
圣诞老人问题 424
对Haskell的一些思考 434
结论 435
致谢 436
第25章 句法抽象：syntax-case 展开器 437
syntax-case简介 442
展开算法 444
例子 456
结论 458
第26章 节省劳动的架构：一个面向对象的
网络化软件框架 459
示例程序：日志服务 461
日志服务器框架的面向对象设计 464
实现串行化日志服务器 470
实现并行日志服务器 475
结论 481
第27章 以REST方式集成业务伙伴 483
项目背景 484
把服务开放给外部客户 484
使用工厂模式转发服务 487
用电子商务协议来交换数据 489
结论 494
第28章 漂亮的调试 495
对调试器进行调试 496
系统化的过程 498
关于查找的问题 499
自动找出故障起因 500
增量调试 502
最小化输入 505
查找缺陷 505
原型问题 508
结论 509
致谢 509
进一步阅读 509
第29章 代码如散文 511
第30章 当你与世界的联系只有一个按钮时 517
基本的设计模型 518
输入界面 521
用户界面的效率 535
下载 535
未来的发展方向 535
第31章 Emacspeak：全功能音频桌面 537
产生语音输出 538
支持语音的Emacs 539
对于在线信息的简单访问 551
小结 558
致谢 561
第32章 变动的代码 563
像书本一样 565
功能相似的代码在外观上也保持相似 566
缩进带来的危险 567
浏览代码 568
我们使用的工具 569
DiffMerge的曲折历史 571
结论 573
致谢 573
进一步阅读 573
第33章 为“The Book”编写程序 575
没有捷径 576
给Lisp初学者的提示 576
三点共线 577
不可靠的斜率 580
三角不等性 581
河道弯曲模型 583
“Duh！”—我的意思是“Aha！” 584
结论 586
进一步阅读 586
后记 589
作者简介 59
