亚马逊：http://www.amazon.cn/%E6%AD%A3%E5%88%99%E6%8C%87%E5%BC%95-%E4%BD%99%E6%99%9F/dp/B007X6O6J0/

当当：http://product.dangdang.com/product.aspx?product_id=22702127

京东：http://book.360buy.com/10972570.html

China-Pub：http://product.china-pub.com/199266

有趣的是，预售阶段就登上了京东的24小时分类畅销榜，感谢大家的厚爱。

总的来说，程序员可算是英语水平比较好的群体，因为在这个行业，英文资料是最全面、最及时，对英文资料的需求也最迫切的。因此，就我的观察，即便刚入门不久的程序员，面对陌生的问题，一般也能查阅英文文档，找到需要的信息。但是另一方面，我也发现，经常阅读英文文档的程序员，英语水平许多时候却不像“经常阅读英文”的样子。应《程序员》的编辑邀约，我在这里列几点自己的学习心得，供大家参考。

第一，既要看代码，也要读文档。

读文档只读代码，是很多程序员的习惯，也是导致程序员虽然读了很多英文资料，英文水平却没有相应提高的原因之一。以前曾在《程序员》上看到介绍阅读技术图书方法的文章，提出过“先代码后文字”的方法，也就是“先看代码，看不明白再看文字”。这种阅读法能极大提高阅读效率，但如果技术图书只看代码就足够，还要文字干什么呢？很多时候，代码只是冰山一角，代码背后的思维和逻辑才是真正的重头戏，只有写成文字才能解释，也只有阅读文字才能理解。

比如，两段代码都是 x = 5; 看起来没差别，但一段的文字说明是“x should be not more than five”，另一段的文字说明是“x should be no more than five”。不查词典，你能弄清楚两种说法的区别吗——前者是“x必须小于等于5”，后者是“x应当只有5”，意思不同，应用的方法与场合也不相同。

近年来，有越来越多的技术人员投身译介活动，这本来是一件好事，但如果阅读能力不过关，反而会造成更多的困扰。经常有希望翻译技术文档的程序员来找我讨论翻译问题，希望了解一些句子应该如何表达。一开始，我也认为这是中文表达的问题，但后来逐渐发现，其实更多的问题出在英文阅读上，所以我的回答经常是：你觉得作者这里说的是什么意思？引导对方把原文的意思逐步表达出来，其实这时候，真正的译文已经浮出水面了。

最近的例子来自这句话：But as with any web-based system, atom-based solutions trade latency for scalability, making atom often inappropriate for very low-latency notifications。这句话之所以难翻译，问题似乎在于，除去句子的主干，之前有一个But as…， 之后又有一个making…。然而我最后发现，对这个句子有疑问的程序员其实根本没搞懂trade…for…的用法（翻译为“基于atom的解决方案需要权衡延迟性和扩展性”），如果明白它是“牺牲xx换取xx”之后，整个句子就相当好理解，也非常容易翻译了：与所有基于web的系统一样，基于atom的解决方案为追求可扩展性，增大了延迟，所以atom往往并不合适用对延迟要求极低的提示。

要解决这个问题，首先要做的是改变“只看代码不看文字”的习惯，或者至少要做到“阅读文字之后，能明白它的意思与代码是一致的”；另一个有效的办法是通过阅读纯文字的英文资料来学习某些新的知识（比如关于深入原理的细致讲解），这个方法我推荐给许多朋友，非常有效。

第二，注意读音。

以前总听人说，中国人学了很多年英语，其实是哑巴英语。不知道现在的情况有多少改观，但就我所见，不少程序员虽然阅读了大量英文资料，也会加入英文的讨论组，也敢开口说，但是还会在读音上出现许多问题。这里说的“读音”，并不是字正腔圆的口音，而是一些术语的读音。

计算机科学的术语来源非常广泛。比如设计模式里，有一种模式叫Facade，许多人往往直接读作’fəkɑ:d，其实这个词来自法文，正确的读音其实是fə’sɑ:d；再比如伪代码的“伪”pseudo，正确的读音是’su:dəʊ，但是我很少遇到能把它读对的程序员，许多人干脆不会发这个音。

也许有人说，这些问题不重要，大家“将错就错”，约定俗成就好了，但事情没有这么简单。最近我参见某个技术聚会，有位嘉宾（技术高手）把框架名chameleon（变色龙）读成了’tʃəmiljən，而正确的读音是kə’miljən，因为没有文字资料，许多人听了半天才知道他说的是什么，一些不熟悉chameleon的听众更是到结束也没明白。中国人聚会尚且如此，如果有机会参加中外技术交流，读错造成的问题就更大了。

解决这个问题有一个非常好的办法，就是学习美国大学的公开课，耶鲁、斯坦福等学校的计算机系都放出了许多高质量的公开课，学习其中的一些精品课程，不但能夯实基础，还能顺带学会许多每天都要遇到，但不会或者读错的术语。比如我就从中学到，数据类型char的读音是kɑ:，而不是tʃɑ:（经多位读者指出，这个例子有误，kɑ:和tʃɑ:都是可以接受的）。

第三，锻炼英文表达。

如果你背过单词，大概听到过“被动单词”和“主动单词”的说法，前者是指“看到了能认出来”的单词，后者指“表达时能主动应用”的单词。就我的观察，许多程序员掌握的大多数英语，都属于“被动英语”——看到了能认识，但要表达同样的意思，未必说得出来。

平时这样似乎没有问题，可是到了查阅资料时，不会表达就成了大的障碍。相比中文技术资料世界中“无责任/不负责转贴”泛滥的情况，英文技术资料的质量要高得多，Google搜索资料的准确性也远高于百度；但是，要能够顺利应用英文资料，需要“主动”输入信息，描述问题，这时候“被动英语”就成了大问题。

我自己多次遇到过这样的情况：即便答案近在咫尺（输入正确的关键词，Google的第一条结果就是答案），但程序员就是一筹莫展——因为他不知道计算机的“嘟嘟”声是beep，不知道搜“多线程”资料应该用concurrency，也不知道“死机”是system halt，“黑屏”是blank screen，“（登录时）不停返回”是infinite loop……

要解决这个问题，最好的办法是在阅读资料时多用心，记住这些说法；另一方面，没事的时候多浏览stackoverflow之类的网站，不要因为问题与自己无关而忽略，多留心这些问题到底是什么，是如何表达的。这样，在自己遇到问题时，才能迅速找到可能的解决方案，节省时间。

有人说，以汉语为母语的程序员，学习英语已经是迫不得已，不但要会阅读，还要会读、会表达，真是难上加难。这种说法有一定道理，但是在目前并没有更好的解决方案，学会阅读、认准读音、锻炼表达，确实可以给自己带来好处。长远来看，要改变这种情况，需要中文技术圈的所有人员努力贡献高质量的资料（原创和翻译都可以），如果只是“无责任转贴”，既不亲自验证，也不整理格式，中文技术资料的整体质量只会持续恶化，反向逼迫更多的人把英语学好。

其实在此之前，我一直混迹于互联网的圈子，自认为接触过一些真正的东西，比如大规模数据的抓取，海量数据的存储和处理，在线系统的维护……客服、文案等等工作也有涉及。我想，太阳底下没有新鲜事，跨界虽然是在不同的领域，做的事情大抵还是这些。但是真正投身实业，才发现事实远非自己想象的那样。

这方面突出的例子之一，就是虚拟世界和现实世界的交流。从某种方面来说，互联网或者纯软件开发，更像在理想的虚拟世界中进行，可以脱开现实的束缚，只关心核心的模型。“发一条确认的消息”是非常普通而且常用的操作，你用Java也好，C#也好，PHP也好，只要按照约定发送这条消息，结果都不会有多大差别；落实到现实世界中，情况要复杂许多：消息必须有实际的载体，有发送的动作，不同的载体和动作，又对应到不同的效率和准确率。举个现实的例子：许多客户端软件，通常要求输入条码识别产品，然后用键盘（鼠标）操作一系列对话框、选择框，执行后续的操作。这个流程看起来没什么问题，但是“扫描-敲键盘”的操作在对处理效率要求很高的情况下，却会成为瓶颈。对此，可行的解决办法是，将键盘/鼠标操作统一为几种消息，比如“是”、“否”、“取消”、“确认”，把这几种消息对应到特殊的条码，将这些条码打印出来，贴在墙上，并辅以不同的提示音。这样，需要输入“是”的时候，只需要用扫描枪扫墙上贴着“是”的条码，并确认听到提示音，就可以完成。大部分时候，操作员的手不用离开扫描枪，甚至不怎么用看屏幕，效率自然大大提高。深入学习了解每个操作、每种功能的具体发生情境，是从互联网/纯软件转到实业开发中，相当重要的一点。

另一方面，实业里有许多领域和环节，因为某些限制，一直没有建立完善的虚拟世界（概念模型），如果能够妥善运用技术突破这些限制，同样能够大大提高操作的效率和质量。比如在物流运输中，“封箱带”部分承载着“保证货物运输过程中不被调换”的职能，但其实“保证不被调换”并不只能依靠封箱带这种手段。如今可以通过先进的设备和完善的系统，记录追踪每一个环节中货物的状态，尤其是重量——进入某个环节时，重量是多少，离开某个环节时，重量又是多少，即便货物被拆分，总重也应当保持不变……前一段时间报道出来的iPhone手机在运输过程中被调包的案件，我注意到，盗贼精心制作了和真iPhone手机同样重量的模具，这样瞒过了各个环节，到最终开箱才被发现，看来是深入了解过整个流程的。

以上都是比对技术思维和现实思维，如果换一个角度，从互联网的视角来看企业开发，又会有新的感受。就我的经验，企业开发中，有两个方面可以大量借鉴互联网开发。

第一是借鉴互联网开发的松耦合、混搭（mashup）思维。传统的企业开发虽然也强调分层，但大多必须严格地按照某些框架和套路来进行，开发人员更主要的工作都是“填格子”，这样有两个弊端：选用的框架和套路并不一定合适，尤其不适合今天迅速变革发展的节奏，开发人员的思维和视野也比较受限，难以交付高质量的成果。而互联网开发虽然比较“乱套”，但天生就强调松耦合，强调“服务意识”，许多开发人员天生就知道调用网上的各种服务，受其影响，也愿意将自己的功能做成服务（而不是一段源代码或一个二进制程序）。在一个相对复杂的系统里，完善的文档说明固然不可缺少，但架构同样重要，各个功能是做成服务，还是做成源代码、二进制程序，很可能极大地影响未来的开发难度和开发成本。这方面，企业开发可以多向互联网开发取经，实际上，许多从互联网行业总结的经验，已经被证明完全可以用于企业开发，比如如今流行的REST模式，就不乏成功的企业实施案例。

第二是借鉴互联网的产品思维。传统的企业开发，更像功能的堆砌，功能的组织和引导都很成问题。我曾留意观察过一些大型企业的ERP系统，虽然看似强大，员工使用起来却叫苦不迭，突出问题界面无序，功能杂乱，数据密密麻麻，很难找到自己需要的信息，操作也很繁琐。而互联网开发早已进入“体验至上”的年代，用户习惯了“凭直觉”操作；在这表象之下，功能并不是少了，而是多了，并不是简单了，而是复杂了，只是以更直观、更清楚地方式呈现给用户，并且需要分析用户的行为，不断调整。两相对比，如果能在企业开发中多一些产品的思考，多一些用户体验的思考，往往会受到良好的效果。现身说法是，我们分析了几个月内，所有员工对系统中某个功能的调用操作行为，总结出若干特点，再加以优化，服务器的负载减轻了很多，员工的操作也简便了很多。在企业系统里，这类工作往往是大有可为，而且收效显著的。

前言

提到正则表达式，许多人很有点不屑一顾：这东西，不登大雅之堂，再说也不是总要用到，何必专门花时间学习？

没错，正则表达式并不是“总要用到”，但到了需要的场合用不上，往往产生“一分钱难倒英雄汉”的尴尬。经常需要处理文本的程序员自然会知道正则表达式的价值，其它的程序员如果不会正则表达式，即便开发的领域与文本处理没什么关系，也难免“躺着中枪”的命运——前几天我遇到一个问题，将一行长长的地址拆分成多行，负责这部分的程序员日常的工作只是制作PDF而已，拆分地址是很“边缘”的功能，但不会正则表达式就无法准确折行（一般需要在标点符号出现的地方折行，而不能只在空白字符处折行，但是不同语言中的标点符号各有不同），结果一筹莫展；相反，如果了解正则表达式，就可以很容易地处理各种语言中的标点字符。

以我的开发经验来看，专门花点时间掌握正则表达式，确实是非常有必要的。目前可以见到的关于正则表达式的书籍和资料已经有不少，但又各有不足。

在互联网上，流传着一些编程语言的正则文档和《30分钟教会你正则表达式》之类的帖子。这类资料的好处是简单直接，查到了，如果有现成的例子，而且适用于自己的语言，可以直接拿来用；然而，其坏处也是简单直接，因为缺乏背后原理的讲解，如果找不到现成的例子，或者找不到能在自己所使用语言中行得通的例子（须知道，同样的正则表达式并不能直接套用到不同的语言中），则束手无策。

在正式的出版领域，已经有《精通正则表达式》、《正则表达式必知必会》之类的书籍出版，尤其是前者，堪称关于正则表达式的经典著作，如果想认真学习正则表达式，这类书籍是必须阅读的。但是这类书籍也有一个弱点，即它们都是从英文版本翻译而来，更多地侧重英文文本的处理，身为中文世界的开发人员，我们经常需要处理中文文本，对于处理英文之外的字符，正则表达式已经提供了足够丰富的功能，但如何用对、用好这些功能，资料却很匮乏。

我经常需要给人讲解正则表达式的相关知识，时常惋惜的是，开发人员为这些问题所困然；正因为如此，本书的写作动机便是着力弥补现有资料的缺陷。

相对于正则文档和速成教学帖子，它深入讲解了匹配背后的原理，往往会举一反三，告诉读者，这里为何这样写，如果改成其它形式，会造成什么结构；并且，集中讲解和比较了多种语言中正则表达式用法的异同，方便读者把现成的正则表达式“移植”到自己的工作环境中。

相对于《精通正则表达式》等正式的书籍，本书辟出专门的内容讲解语言和编码，告诉读者如何设定编码，如何正确处理中文等字符，另外，本书还涵盖了.NET、Java、JavaScript、PHP、Python、Ruby六种常用语言，对每种语言给出专门章节，不但详细介绍了语言中正则表达式的用法，更点明了版本之间的细微差异，不但可以作为专门学习的教材，还可以成为有用的参考手册。

本书的结构

本书可以分为三大部分。

第一部分主要讲解正则表达式的基础知识，覆盖常见正则表达式中的各种功能和结构。看完前面三章，就可以基本弄明白现在流行的各种正则表达式；尤其如果你之前有一些经验，会觉得阅读起来并不困难。但是我也希望读者不要忽略其它的内容，断言和匹配模式现在已经是正则表达式的“标准配备”了，而且确实可以派上大用场，所以第4章和第5章的内容，即便不是很熟悉，阅读起来可能有一些麻烦，也不应该忽略。最后的第6章，则厘清了正则表达式在使用中的若干疑惑，了解它们，你就可以相对自由地在正则表达式的世界里行走了。

第二部分主要讲解关于正则表达式的更深入的知识，这一部分用三章的内容，详细探讨了编码问题、匹配原理、解题思路。这部分内容更抽象，需要多花一点时间来阅读和理解，但是它们确实可以帮你在正则表达式的世界里登堂入室，脱离“术”的层面，掌握万变不离其宗的“道”。

第三部分的作用是接地气，将之前介绍的各种知识落实到六种常用语言.NET、Java、JavaScript、PHP、Python、Ruby中来。每一章的开头有正则功能列表，其中的功能都对应到前面部分的讲解，这些功能的具体应用实例，以及不同版本之间的差异，则在章节中详细讲解，每一章的最后还给出了常见任务的示例代码，方便日后查询。在最后，第16章简要介绍了正则表达式在Linux下常用工具vi、grep、awk、sed中的使用，并通过一个实际的例子将这几种工具串起来，对比说明了它们适合解决的问题。

在本书的最后提供了用作参考的附录，分为三部分。

第一部分是正则表达式的常用功能在不同语言中的比对，希望能给需要在多种语言中使用正则表达式或者移植正则表达式的读者来说提供一份有用的参考；第二部分给出了若干常见的正则表达式，比如匹配邮政编码、身份证号、手机号、QQ号、电子邮件地址等等，希望能成为常见问题的“速查手册”；最后一部分列出了常用正则表达式的工具和资源，方便大家调试自己的正则表达式，以及继续深入学习。

本书的读者

本书适合以下几类读者。

经常需要进行文本处理（比如日志分析或网络运维）的技术人员。这些读者或许已经熟悉了正则表达式的基本用法，但面对日益复杂化和海量化的数据，阅读本书可以帮助你更准确、更高效地处理文本，提升自己工作的价值。

熟悉常用开发语言的程序员。虽然这些读者不需要专职进行文本处理，但源代码和许多数据其实也是文本，如果不会正则表达式，在偶然遇到处理源代码或文本数据的任务时，往往会产生躺着中枪的无力感。本书第三部分可以帮你迅速找到有关的例子，并落实在自己的编程语言中，当然前两部分也非常有必要，因为它们可以帮你夯实基础。

已经对正则表达式有一定了解的读者。这些读者虽然能用正则表达式解决常见的任务，不一定了解正则表达式的编码问题、匹配原理、解题思路，仔细阅读本书的第二部分，可以深化并完善对正则表达式的理解，而第三部分详细比较了使用正则表达式时各种语言、以及同一种语言中各种版本的差异。所有这一切，应该可以让你对正则表达式的掌握更上层楼。

致谢

一本书的完成，必然离不开众多人的帮忙。

首先需要感谢的是周筠老师和徐定翔、卢鸫翔两位编辑，他们在我写作的最初阶段做了大量细心耐心的工作，完全可以说，没有他们的这些工作，我就不会有写作这本书的念头，或者坚持写完的动力。

然后要感谢的是电子工业出版社的杨福平社长和张月萍编辑，没有他们的关照和辛劳工作，这本书的出版定然会遇到更多的困难。

感谢我的朋友霍炬和韩磊，虽然我之前阅读过《精通正则表达式》，但与翻译和写作结缘，他们给了我莫大的帮助，有了这个契机，才有现在的《正则指引》。尤其值得一提的是霍炬的夫人西乔，精心手绘了这本书的封面，在这里表示诚挚的谢意。

感谢我曾工作过的盛大创新院以及创新院的各位同事（李骏、郝培强、庄表伟、丁宇、许式伟、莫华枫、李道兵、赵劼、樊一鹏、张一宁等），创新院给了大家宽松自由的工作环境，与各位同事的讨论加深了我对正则表达式理解，也为我贡献了许多例子。

感谢张东亮、陆亦斌、孙勇、叶劲峰等各位朋友，愿意拨冗阅读本书的草稿，并提出了大量专业的意见。

感谢何源、陈钢、贺钧、陈驰等读者，试读本书之后提出了大量的宝贵意见，在最后关头打消了我心中的许多忐忑。

在更早之前，我的父母从小就鼓励研究和了解各种科学原理（“玩也要动脑筋”），没有这种思维行为习惯，我很可能浅尝辄止而没有兴趣探究正则表达式背后的图景；此外，在中小学阶段，我的语文老师罗碧玉、郭志鸿、易玺铭培养了我对于文字的兴趣，在大学阶段，东北师范大学文学院的王确老师给了我这个理科生非常多的帮助和指引，在此一并表示感谢，能遇到你们是我的幸运。

最后需要还需要感谢许多为这本书做出过贡献的人，你们的名字我可能暂时无法记起，或者无法一一罗列，但我会在心中存留对你们的谢意。

不妨来看个具体的例子：同样是产生热量，我们可以给电热元件通电，也可以点天然气，还可以依靠摩擦生热，甚至还有很多我们意想不到的方式，每一种方式都其独特之处，这么看来，确实是总有新鲜事；但是从另一方面来看，这些方式可以归类为物理的、化学的等几大类，而其本质，无非是能量的转移，这么看来，说“太阳底下没有新鲜事”，又的确有道理。换句话说，“有没有新鲜事”取决于看问题的层面。通常，从具体细节来看，总是有新鲜事发生，但是分类归纳之后，往往并无新鲜可言。

不过，无可否认的是，面对新鲜事物，一句“太阳底下没有新鲜事”，即便是漫不经心说出来的，也非常有分量，充分体现出极具洞察力的专家的自信——我就知道会是这样；更进一步，不止自然科学领域，在社会科学领域，许多人也在寻找那些恒常不变的规律（或者也可以叫共性、要诀、招式），期望从此收获“太阳底下没有新鲜事”的自信。但是，他们真的能做到这一点吗？

且以近年来受极大追捧的经管类畅销图书为例，这些书之所以畅销，光看名字就已经可知道原因了：《追求卓越》、《基业常青》、《从优秀到卓越》……作者毫无例外地宣称运用科学方法分析得到了伟大（卓越）公司的经营秘诀，并且尽力将书写的生动有趣、引人入胜，旨在让读者闲庭信步间领略到“伟大的公司何以伟大”的秘诀——比如四大要素、六个步骤、八大法则等等，告诉读者成就伟大的公司并不是什么新鲜事。继而，依葫芦画瓢，也可以将自己的事业做到优秀，做到卓越……但是，就我的经验，这么做多半是缘木求鱼，充其量，可以算一厢情愿，只能体现人们对美好图景的幻象，具体原因在下面详述。

首先，经营公司要解决的问题，与自然科学的问题并不一样。自然科学解决的典型问题类似：生产某样产品需要多少原料，经过怎样的物理化学处理等等。但是公司经营要解决的典型问题则类似：根据有限的资源，到底是生产产品甲，还是产品乙，如果选择产品甲，需要按照什么次序，投入多少资源，有多大的市场，预期可以获得多少回报……每一个问题都是新鲜的，都需要具体分析。实际上，畅销的经管书籍也被迫承认这些方面没有多少成文的规律可循，它们大多以“需要有一个清楚而持续的战略”之类的说辞来敷衍。实际上，战略是否清楚，很可能是随着公司的经营而逐渐明晰的，而且很可能需要经常调整战略，所谓“清楚而持续的战略”，更多是事后的总结和包装，并不能在事前确认。

其次，公司经营的成败，很大程度上取决于与竞争对手的互动态势，而经管畅销书往往对此语焉不详，似乎更注重“内功”。实际上，与竞争对手的互动是非常考验脑力的：对这个对手，可能需要采取这种方式，对另一个对手，又需要采取另一种方式；更复杂的是，对手可能会根据你的应对做出调整，于是这一轮应对结束，下一轮应对开始……了解博弈论的人知道，随着双方的互动，形势的复杂程度可能呈指数级增长。同样的策略不可能适用于所有的对手，甚至对同一个对手，在不同的时机，也需要采取不同的策略。某个企业努力将生产效率提高了一倍，同时竞争对手提高了三倍，或者另辟蹊径抢走了市场，这样的例子是屡见不鲜的。

再次是执行，现在流行的说法是“执行至上”、“无缺陷执行”，但是经营过公司的人都知道，不同的人对“执行”的理解并不相同，同一个目标，不同方面的执行力度也是不同的。有时候需要“一鸣惊人”，确保产品在交付时没有任何缺陷，有时候又需要“先开火再瞄准”，一边运营一边改进。在这样复杂的局面下，“执行至上”或者“无缺陷执行”更像是动听的口号，却并不能产生现实的意义。

最后，卓越的公司，很少有始终“追求卓越”，从一而终地贯彻某些恒常不变法则的，它们的“卓越”，更像是一根链条——在每一个时期，在每一种环境下，采取了正确（或者说没太多错误）的策略。Intel在1985年决定全力进入周期较长但利润丰厚的微处理器领域，这是一个冒险的决定，可以肯定的是，当时的Intel并没有刻意追求“卓越”。这些环节前后相继，总的来看才能成就“卓越”，但由结果去倒推，断言甚至要求一直追求长期的“卓越”，则属于本末倒置了。

所以，我的观点是，在社会科学领域，尤其是在公司的经营管理上，很难说“太阳底下没有新鲜事”——每个阶段，每个方面，我们需要解决的问题都是新鲜的，正像之前在《收割庄稼V.S.砍伐大树》里面说的：解决这些问题并不像收割庄稼，而更像砍伐大树，而砍伐每一颗树时，都需要注意到它的形状和方向。如果一定要追求“没有新鲜事”的境界，找到什么恒常不变的法则，很可能只能“到此为止”：这些法则是每个阶段、每个方面、解决每个问题都必须遵循的一定步骤，却不是伟大公司的充分保证。当然，“成就伟大公司并没有什么恒常不变的法则”，倒真不是什么新鲜事。

解决问题的第一步，是认识问题。这一步往往容易被人忽视，认为是多此一举，因为“问题就摆在那里”，所以许多人上来就跳过这一步，直接动手解决，结果大都收效不佳；究其原因，往往忽略了认识问题。比如听到有人说“要求更高的生活质量”，首先应该提问，“更高的生活质量”是什么？是交通状况更好，还是娱乐设施更多，还是商业更繁荣，学校更普及？到现在为止，这些问题并没有明确的答案，唯一清楚的是，现状不尽如人意。这时候要做的，是在了解清楚情况的基础上明确地设定一个目标。这道理看起来简单，真正做起来却并非如此，许多人并不愿意去寻找真正的答案，反而相对随意地“找”了一个目标：面对“更高生活质量”的要求，有些人会根据自己的经验，想当然地认为这是教育资源不够，所以花大力气整顿教育——其实，这么做的人并没有解决真正需要解决的问题，仅仅是依照自己的能力，解决了自己最熟悉、最顺手的问题，并且“以为”这就是真正的问题。

解决问题的第二步，是认清问题。认清问题与认识问题的区别在于，认识问题只是准确地看到一个点，认清问题是从这个点发散开去，联系到更全面、更深刻的内容。比如某人挨了老板的骂，心里不爽，于是他很清楚问题是“心里不爽”，第一步已经做到了。要解决这个问题，可以找朋友出去大吃一顿，排遣郁闷；也可以好好反思一下，到底为什么挨老板的骂，想通了也就舒坦了。两种办法，都可以解决“心里不爽”的问题，长期的效果却大不相同。还有些时候，我们需要认识到，自己是在一个复杂的系统里解决问题，只解决一个点上的问题，很可能导致其它方面的问题，因为许多因素是此消彼长的——比如为了解决旱灾或者发展需要，大量抽取地下水，初看是保证了用水，但这样做下去，会导致地表沉降等一系列其它问题。所以，仅仅认识问题是不够的，还要能发散、联系四方，认清问题。

解决问题的第三步，是了解信息，制定计划，也就是找到可行的、抵达目标的路径，并将它拆分为若干小部分。在这一步，我们并不能保证自己面对的都是已经已经解决过的问题，可以拿出胸有成竹的方案，所以抽象思维能力非常重要——所谓抽象，就是把具体的问题提升到比较模糊但是通用的形态，经由此关联到已有的知识。一个人或许没有制造手表的经验，也不知道如何制造手表，但他在卷烟厂工作过，所以知道需要原料，按照一定的工序，还需要工人和能量。看来，制造手表也需要采购原料，按照一定的工序组装，并且需要有专业经验的人，并且需要能源支持。在这个例子里，他通过抽象，将手表制作提炼到“原料、工序、人员、能源”的形态，嫁接上了自己之前的经验。

解决问题的第四步，是估量时间序列。一般认为，我们生活在三维空间，所以我们对于空间问题，往往有强烈的直觉；然而，时间同样在我们的生活中扮演着重要的角色，可是我们经常忽略时间结构，即便在时间方面进行了考虑，直觉也非常有限。多个实验和大量事实已经反复证明，人的直觉，在估量时间序列时往往有很大的偏差，即便我们知道疾病的发病率，还是会低估感染者的人数，即便我们知道复利的利率，还是不愿意存钱，因为觉得收益太少。准确地说，普通人往往根据线性模型来进行时间推演，专业人员则清楚，增长函数有宽得多的范围，所以他们往往能选择最合适的函数模型，而不是盲目地根据“感觉”或“直觉”来做判断，所以能做出更准确的预测和规划。

或许有人说，这样做是简单问题复杂化了，把事情“机械化”到这种程度是没有意义的，但是我不这么看，做这种细细的分解，正是为了更有效率、更有效果地解决问题。
《战争论》的作者克劳塞维茨曾说：“战争，从他的最高角度来看，不是由大同小异的无数细小事件构成，而是由需要分别处理的，具有决定意义的各个重大事件构成。战争不像长满庄稼的田地，收割时不需要考虑每颗作物的形状；战争更像长满大树的土地，在砍伐每一颗树时，都需要注意到它的形状和方向”。同样，每天我们都需要解决大量的问题，这些问题各不相同，解法也不能千篇一律。如果非要有什么“以不变应万变”的秘诀，只能是针对每个问题，都能做到认识问题、认清问题、制定规划、估量时间序列这写步骤，并把它们养成习惯，内化到每一次行动当中，才可以做到有所针对地“砍伐大树”而不是简单机械地“收割庄稼”，真正解决“如何解决问题”的问题——随着信息技术的飞速发展，计算机已经承担了越来越多的“收割庄稼”的工作，这时候，能够“砍伐大树”才最能体现人类的价值。

可是后来，我逐渐发现，用计算机解决许多问题，依靠的并不是“傻算”加上生搬硬套生活中的直观方法，而是“别开天地、自成一体”。我曾经遇到过一个每日运营数据分析的程序，需要10小时才能计算出结果（在当时的业务环境下，这速度完全不可接受），其思维就是生活中的直观方法。我花了一天时间来改进算法，最后只需要5分钟。这个例子我记忆犹新，它充分说明：强大的计算能力，并不能直接带来充沛的解决问题的能力；用计算机解决复杂问题，必须懂得计算机的“玩法”，理解计算机的逻辑，然后才谈得上妥善运用计算能力。

怎样才算懂得计算机的“玩法”，理解计算机的逻辑呢？可以举个排序的例子来说明。

排序，这几乎是我们每时每刻要遇到的问题，对普通人来说，排序就是把一堆东西按大小顺序组织起来；对应的，许多变成语言提供了现成的sort函数，对某些程序员来说，排序就是查找语言文档，调用这种函数即可。但是，事情真的这么简单吗？

为进行排序，需要定义一种关系R用来比较任意两个元素，以常见的小于（<）关系为例，a < b 可以表示为 a R b；现在要做的是，对于排序结果中的任意两个元素Xi, Xj，如果i < j（也就是说Xi在Xj之前），必然存在关系Xi R Xj。

这段话看起来繁杂，意义却很重要。常见的数值类型”天然“就可以进行小于计算，所以对不少程序员来说，a < b中的 <，和返回true或者false的布尔运算符没有区别。这样“凑合”确实可以解决简单问题，却无法处理复杂对象的排序，把人按照身高排序，把货物按照发送的远近排序，把向量按照夹角排序；因为这些时候，排序的对象并不是身高、距离、夹角的度数，而是人、货物、向量。还有些人，大概了解关系的概念，但没有考虑“对排序结果中的任意两个元素，关系都成立”，所以排序结果经常出现“局部有序，全局无序”的情况。

用计算机解决排序问题，必须首先定义“关系”的概念，它在编程语言中存在对应物——常见的数值类型往往会提供默认的排序关系，也可以由用户指定排序关系，比如Java中的Comparator类，Python中的cmp函数，都对应着关系的概念。

以上两点都了解清楚之后，就可以开始选择排序算法。请注意，排序算法与排序关系是彼此独立的——不同的排序关系，可以采用同样的排序算法；同样的排序关系，可以应用到不同的排序算法（这里体现的，是计算机科学中的“责任分隔”、“低耦合”的原则）。

学过算法的人大都记得，常用的排序算法有几种：插入排序、快速排序、归并排序等等。编程语言一般会提供通用的sort函数，确保排序的结果是正确的，所以是不是就不需要了解排序算法了呢？

一般来讲，如果排序的规模比较小（小于千），插入排序是足够快的，也足够简单，同时只需要O(1)的额外空间；如果排序的规模较大，那么选择快速排序比较合适，只是它需要O(log n)的额外空间；如果排序的规模更大，内排序已经不合适，则应当选择归并排序之类的外部排序（External Sorting）算法。

对应到实际开发中，经常会遇到各种场景，比如资源非常有限（典型的就是移动开发），或者运算量非常大（海量数据的处理），这些时候需要程序员理解各种排序算法之后的原理，如果不分青红皂白，只管随意抓一个sort函数来用，结果很可能不只是计算缓慢，而是根本无法实行。所以说，要用计算机高效地解决真正的问题，必须懂得计算机的“玩法”，理解计算机的逻辑。

亨利·福特曾说：“人们需要的是汽车，而不是更快的马”。相应的，汽车时代有汽车时代的规矩和逻辑，同样是赶路，已经不可能再用骑马的规矩和逻辑进行。计算机也是如此，我的经验是，“基本上，计算机可以无限延伸人的能力，前提是懂得计算机的逻辑”，如果在高速增长的计算能力面前还只能延续手工时代的直观方法和简单逻辑，充其量，也只是骑高铁的马夫。

第一部分

第1章 字符组

1.1 普通字符组
1.2 关于Python的基础知识
1.3 普通字符组（续）
1.4 元字符与转义
1.5 排除型字符组
1.6 字符组简记法
1.7 字符组运算
1.8 POSIX字符组

第2章 量词

2.1 一般形式
2.2 常用量词
2.3 数据提取
2.4 点号
2.5 滥用点号的问题
2.6 忽略优先量词
2.7 转义

第3章 括号

3.1 分组
3.2 多选结构
3.3 引用分组
3.4 非捕获分组
3.5 补充

第4章 断言

4.1 单词边界
4.2 行起始/结束位置
4.3 环视
4.4 补充

第5章 匹配模式

5.1 不区分大小写模式
5.2 单行模式
5.5 补充

第6章 其它

6.1 转义
6.2正则表达式的处理形式

第二部分

第7章 Unicode

7.1 关于编码
7.2 推荐使用Unicode编码
7.3 Unicode匹配规则
7.4 单词边界
7.5 码值
7.6 Unicode属性
7.7 Unicode属性列表
7.8 POSIX字符组

第8章 匹配原理

8.1 有穷自动机
8.2 正则表达式的匹配过程
8.3 回溯
8.4 NFA和DFA

第9章：常见问题的解决思路

9.1关于元素的三种逻辑
9.2 正则表达式的常见操作
9.3 正则表达式的优化建议
9.4 别过分依赖正则表达式

第三部分

第10章 .NET

10.1 预备知识
10.2 正则功能详解
10.3正则API简介
10.4 常用操作示例

第11章 Java

11.1 预备知识
11.2 正则功能详解
11.3正则API简介
11.4 常用操作示例

第12章 JavaScript

12.1 预备知识
12.2正则功能详解
12.3 正则API简介
12.4 常用操作示例
12.5 关于ActionScript

第13章 PHP

13.1 预备知识
13.2 正则功能详解
13.3 正则API简介
13.4 常见正则操作举例

第14章 Python

14.1 预备知识
14.2正则功能详解
14.3 正则API简介
14.4 常用操作示例

第15章 Ruby

15.1 预备知识
15.2 正则功能详解
15.3 正则API简介
15.4 常用操作示例
15.5 Ruby1.9的新变化

第16章 Linux/Unix

16.1 POSIX
16.2 vi
16.3 grep
16.4 awk
16.5 sed
16.6 总结

附录

附录1 常用语言中正则特性一览

附录2 常用正则表达式及讲解

附录3 常用正则表达式工具及资源

这是一个许多人都赞同的答案，而且从此细想开去，可以发现很多问题：早先的程序员，并不是不会被产品经理折磨，而是几乎根本没有产品经理来折磨。在开发还主要服务于具体问题，以定期发布一版软件为主要形态的阶段，功能的有与无是最大的问题；而在开发深入到生活的细节领域，计算机用来解决各种问题，持续发布成为常态，竞争又日趋激烈的情势下，产品的重要性才日渐凸显出来——我们都习惯了不仔细翻阅说明书，凭直觉使用各种功能，我们也习惯了在系统的各种“提示”下直抵问题的核心。这些便利，很大程度上是赖产品经理所赐。也正因为如此，越来越多的人投身于产品经理，在这种爆发性增长的阶段，鱼龙混杂，难免苦了在一线开发的程序员。与其忍气吞声，不如取而代之，产品经理由是成了许多程序员的选择。

然而就我所见，许多人不是产品经理时苦不堪言，真正坐上了位子却左支右绌，这种例子并不少。究其原因，或许还是经验太过片面，细节计较太多，内心没有棋局。产品经理的工作重点是什么？属于哪个部门？职责边界在哪里？需要着力培养哪些方面的素质？应当与哪些部门沟通，如何沟通？这些关于产品经理本身问题看似有些“虚”，但若回答不好就去做产品经理，却绝难说是称职的。

要回答这些问题，国内已经有不少优秀的产品经理原创作品可以参考，我愿意同时推荐的，是Marty Cagan写的《启示录：打造用户喜爱的产品》。作者是eBay的高级产品经理，在这一领域着力多年，这本书却绝非巨细靡遗的大部头，而是论述产品经理若干核心问题和经验的精当小册子——实际上，我是在火车上花两小时看完的，但深深记住了产品经理职责的三方面：人员，指负责定义和开发产品的团队人员的角色和职责；流程，指探索和开发产品时，反复应用的步骤和成功的实践经验；产品，指富有创意的产品应具有的鲜明特征。

相应的，这本书也分为三个部分，针对每一个方面细致列出若干主题，比如在“人员”部分，就总结了产品经理的职责，与相关职位的差别及边界，产品经理应具备的素质，工作中应当注意的问题等等。这是我非常喜欢的编排方式，看过Effective C++/Java的人都知道，这种编排方式确实是Effective（有效）的；难能可贵的是，作者并没有止步于这些“务虚的探讨”，还根据经验分析了常见各种选择的优劣，比如将产品团队归入技术部门，往往会埋没于细节之间，归入市场部门，又混淆了产品营销和产品管理的职责；再比如产品经理太听信客户或者太过干涉设计细节，往往容易被“怎么做”迷惑，忽略了“做什么”。如果靠自己提炼这些知识，恐怕得有足够多的经理，吃过足够多的亏，经过足够多的反思；不过有了Marty的书，有志从事产品工作的人，肯定可以少走很多弯路。

当然，也正如书名所说，是“启示”而不是“操作手册”，它并没有提供繁复全面的指引。读完第一遍，我收获了很多启示，要完善正确的产品意识，甚至成长为称职的产品经理，还有很长的路要走；不过我想，我会时常翻一翻《启示录》，带着经验来看它，是常看常新的。

我是在2003年接触翻译的，当时美国对伊拉克动武，国内的报道非常奇怪，为了在论坛上争论，加上自己还在读书，时间比较多，就开始翻译一些外国媒体的报道，发在论坛里。初做翻译的最大感受是堵得慌，从来没想过要把意思表达明白会这样困难，就好像要说话，却发现舌头不受自己控制。所以一千字左右的译文，需要花费四到五个小时，而且完成之后大汗淋漓，心力交瘁。在这段时间，我陆续“义务”翻译了十万字左右的资料，因为是“兴趣所在”，所以不但不觉得累，还愿意花心思去琢磨。另外要特别感谢秋风先生和林猛先生，他们愿意花精力修改我刚入门的译文，指出各种问题，并且指明了很好的学习书籍和词典。回想这段经历，我最大的收获是，许多有意义也值得做的事情，一开始不可能带来明显的回报，甚至都看不到有什么明显的回报，但这不是拒绝投入的理由；另外，精当的指点也是非常重要的，这样自己可以少走弯路，迅速提高（也正因为如此，我不太赞同译言网之类的翻译社区里互相夸赞安慰的风气，没有批评和挑错，译者很难进步）。

但这些还只是开始，我自己翻译最大的收获，还数翻译《精通正则表达式》（第3版）。当时接这本书的翻译，也是有点不知天高地厚，70万字，500页的书往桌上一放，才感觉苦上心头。等到煎熬过去，真正完成，才发现最大的收获并非来自文字本身——技术书籍的语言比较简单，而且，今天看来这本书的译文还有很多可以改进的地方；也并非来自经济收入——《精通正则表达式》2007年面世以来，重印7次，我拿到的版税其实非常有限。让我意想不到的最大的收获在于，如何面对庞杂的任务，鞭策自己日复一日地去执行，最终实现自己的目标。

人常常生活在被动在之中——读书时，不能按时交作业，会被处罚甚至拿不到毕业证；上班时，不能按时完成任务，会被扣工资甚至开除。但是翻译，尤其是技术翻译，经常是业余性质的劳动，是译者兴趣所致自己给自己定下的目标。任务本身缺乏足够的刚性和强制力，所以拖延甚至毁约，其实是很常见的情况，至少就我所知是如此。这时候，能够按部就班地执行自己给自己定的目标，其实是非常严峻的考验。但是，翻译的刺激感与成就感又胜过普通的“自我实现”，许多需要“自我实现”的目标，并不能得到外界的认同，翻译则不是如此，你真正做完了，做好了，就会看到外界的反应。能够真正完成一步作品的翻译翻译，不但能够磨练自我归束的能力，也可以收获其他人的认可，对生活的感受也会发生改变：许多看似稀松平常的任务，其实需要耗费海量的心力，从此生活会更加踏实，也更能珍惜其他人的付出。

在现在的环境下，在金钱和文字之外的所得，才是翻译最大的收获，能认同这一点，才有足够的动力，去面对“收益不足”的挫折感。网上有人说每小时可以翻译一千字，月收入轻松过万，我承认我做不到，我只有在事先通读全文，并且精力饱满的前提下才可能达到这个速度。关于文字，翻译是可以锻炼提升对文字的水平，但锻炼提升的速度却是会变化的，在经过一两本书的考验之后，哪怕你一直在整理和反思，提高的速度也会不可避免地降低，可能经过相当长的时间，可以达到炉火纯青的地步，但对于把翻译作为（值得认真对待的）业余爱好的人来说，花大量精力炼到炉火纯青未必可取。所以我的建议是，翻译之前，想明白自己能获得的提升，决定认可它，再通过认真翻译一些文本，即可。之后是否继续翻译，完全取决于自己，但通过翻译锤炼出来的自我归束的能力，却可以应用在生活中的各个方面，而且受益无穷。

看到这里，有人可能要问，大部头作品的翻译怎么办？我想，比较合适的方式是协同翻译——多人合作，明确分工，每个人翻译其中一部分，并互相审读评阅，这样既能够翻译出大块头的作品，单个译者的任务也不会太重。现代的翻译协同机制已经大大进步了，远非之前“导师找几十个研究生包干”，目前已经出现了很多工具，译者能互相借鉴、评阅，编辑也可以通过这些工具，像管理项目一样，管理整本书的进度；这样下来，最终译文的质量有相当的保障。就我的了解，国内已经有不少社区采取这种方式，翻译出版了一批不错的书籍，长期来看，这应当是技术书籍翻译出版的方向。