今天在互动出版网看到《七周七语言：理解多种编程范型》一书已经开卖了。看到自己参与翻译的第一本书出版了，心中还是很愉悦的，因为自己的辛苦付出终于有了结果。

一、缘起

能够参与到这本书的翻译完全是机缘巧合。记得2011年初我启动了一个《Programming in Haskell》的公共翻译项目，可是由于欠缺版权的考虑，中途不得不终止了该书的翻译。当时经dreamhead介绍联系到图灵的刘江总编，希望人邮能 引进版权以促成该书的翻译，但刘总编考虑到该书是有关Haskell这门"小众"语言的，引进后受众面小，书很可能卖不出去，商业价值不高(后得知该书作 者Graham Hutton博士已经在与某出版社谈中文版版权的事宜了，并已经委托其一位同事进行中文版的翻译工作了)。不过刘总编说图灵当时已经引进了《Seven Languages in Seven Weeks》一书的中文版权，但第一译者戴玮因工作学习繁忙，可能无法按期完成全部翻译，问我是否愿意参与翻译。我的最初目标就是翻译一本英文技术书籍， 有这样的机会，而且书还可以在国内出版，于是我就欣然接下了这个翻译工作。

二、翻译过程

经过试译审核，顺利与图灵签订了翻译合同，我将负责翻译该书的Prolog、Scala和Haskell三个章节。正式翻译是在2011年春节后开始的， 为了能在合同规定的第一个时间点交稿，我连续N天翻译到凌晨下半夜，工作日中午午休时间也在抓紧时间翻译，周末也不放松。因为是第一次翻译，生怕自己翻译 的不好，于是对原书中的每句话都字斟句酌，仔细揣摩。另外虽说此书是一本技术书籍，但作者给每门编程语言都赋予了一部电影中的典型人物角色，并用电影中的 情节或人物角色的特征作为章节的导引，这使得每章的开篇十分难于翻译，特别是当我不熟悉语言所对应的那部影片中的那个角色时，翻译更是举步维艰。为此，我 特意看了一遍"雨人(Rain Man)"和"星际旅行(Star Trek)"，重温了"剪刀手爱德华(Edward Scissorhands)"，为的就是能够更精确地定位本书作者所要表达的意思。Scala一章的第一稿提交后，我收到了图灵编辑不错的反馈。于是再接 再励，在2011年4月末交了全部初稿，5月中旬完成了中耕校对；2012年3月份完成排后稿的校对。

三、关于翻译方法和心得

这是我第一次参与翻译项目，说实在的真没有资格谈什么翻译方法，我也不是什么专业翻译人员。但在这本书的翻译过程中还是有若干经验和教训可以与大家分享的。

* 心态

我认识的参与过技术书籍翻译的朋友都说：翻译不是为了赚钱(那些以翻译为谋生手段的职业翻译除外)，这点我深表认同。翻译工作是一件枯燥、辛苦甚至是费力 不讨好(出版后可能被拍砖)的工作。因此翻译前就要摆正心态，弄清楚自己为何要翻译，有了良好心态，才会有持续不断的动力，否则译着译着人就容易产生懈 怠，进度和质量都会下降，你需要这样一种战胜懈怠并持续下去的手段。

* 你是翻译质量的决定者

不要过于期望诸多编辑朋友会拿出百分百的时间对你的翻译内容进行校对，出版社的编辑们太忙了，一个人估计要至少负责10本以上书籍的出版工作，因此你才是翻译质量的决定者，从开始翻译的那一刻你就要保持高质量水准。

* 第一遍就要保持高质量，不要期待你能回头做二次翻译

第一遍翻译时，务必保证按顺序逐字逐句的高质量的翻译，一次到位；遇到难点也不要跳过，而是要集中精神搞定这个难点；否则你就会发现你积蓄的难点越来越 多，严重影响你后续翻译的情绪和心理。不要有回头做全面二次翻译的想法，因为你会发现那基本不可行，二次翻译时你会发现你的思路严重受制于第一次翻译的思 路，因此不仅不会提高什么质量，还会使你变得更加烦躁，严重影响翻译进度。

* 前后一致

保持前后章节的术语、句型等翻译的一致性。这点在翻译和校对时都要重点关注。

* 除了认真还是认真

不是所有人都是翻译天才，大部分译者，特别是技术书籍的译者，可能只是那个领域的从业人员(比如我)，在翻译能力上存在不足。但万事就怕认真，认真可以尽量袮补在能力上不足，也是出品高质量译文的必要条件。

四、关于《七周七语言》一书

从本书的中文名字，你也许会将其与"21天学会C语言"之类的捷径书籍混为一谈，但本书的初衷与那些捷径书籍显然不同。本书意在让你在短时间内了解到多种 编程语言的范式和主要特性，并做简单的对比了解。书的作者也许并不期望你在看完某种语言后就彻底学会了这门语言，那显然不是本书的意图。如今也许是另一个 编程语言百家争鸣的时代，新的语言层出不穷，作者试图帮助大家在如此繁多的语言当中找到一些适合你投资、学习和使用的有前途的编程语言。

书的最终版本我也没有拿到，我也只是看了我所翻译的那三章，因此书的内容好坏我也不能妄加评论。这里是Amazon.com上关于此书的一些书评(中文翻译版)，另外从本书获得了2011年Jolt大奖可以看出本书还是被业内专家一致看好的。

个人感觉出版的有些晚了，如果能与Jolt大奖的公布同步推出也许效果会更好。书的最终纸质版本我也没有拿到，尚不知书的印刷质量如何，另外翻译的质量如何还得需要大家评判。

最后十分感谢翻译过程刘江、杨海玲 、傅志红、李松峰、丁晓昀等各位老师对我的帮助。

昨天中午收到图灵出版的《布道之道 – 引领团队拥抱技术创新》一书，晚上就迫不及待地翻看开来。这是我读过的第一本有关推动组织内部技术变更/创新实践方面的书，感觉书作者对受众的分类很是准 确到位，很多布道技巧也十分值得借鉴。但就我个人多年来的体验来看，组织内部技术布道的结果，不仅仅与受众的类型有关，还与布道者自身的资历、所担任的角 色、组织内部的文化和环境、布道路线以及布道时机和对象的选择有一定关系。下面就是我在这方面的一些粗略心得。

一、技术布道结果的影响因素

我个人也算是组织内部的一个技术布道者，经过多年的碰壁和反思，感觉技术布道的结果好坏与下面的一些因素或多或少有些联系。

* 布道者的资历

无论国内国外(国内可能尤甚)，职场资历这个因素在任何职场活动中都会是一个影响因素，技术布道也不例外。如果你是一个职场新人，也许工作年头不超过一两 年，甚至是刚刚进入职场，你势必人微言轻，并尚未在组织内建立起信任，更重要的是你可能并未深入理解大家面对某种新技术或新实践时遇到的真正困惑以及问题 是什么，这时如果你在组织内尝试大力推动某种技术或实践，效果可能不甚良好：你会发现关心你的提议的受众会很少(除非之前就赢得了上层领导的支持)，你会 受到大家对你的资历的质疑："你才刚来，这东西你自己用过吗？你怎么就知道这东西会对组织带来价值？你讲的这些我都知道，但我们遇到的问题你并没有真正解 决"。记得2007年一位刚刚入司不到半年的新同事(我们得承认这位同事很有技术潜质，也很有技术热情)就在项目组内部大力推广设计模式，并多次在项目组 内部以技术沙龙的方式分享设计模式相关的知识，但效果并不好，以至于若干个月后，这位同事离职后，大家依旧如故的行事，设计模式也并未真正被用到产品代码 设计中。

相比之下，一些组织内资深的布道者反倒更容易推动组织内的技术变革。

* 布道者的角色

一般来说，技术布道的发起者多为组织内的纯技术人员或技术管理者，但也不能排除非技术人员(如：过程改善人员或高层管理者)发起技术或优秀实践的布道。纯 技术人员或技术管理者因其技术背景并深处其中，布道过程中其同理心更强，布道思路更符合大家的胃口，但效果因人因地而异；而过程改善人员或管理人员多半采 用是行政命令的灌输式的方法，强行推进技术或过程改革，这样做常常会遇到抵触或反对意见，短期内可能有效果，但长期结果却往往不佳(当然也有例外)。

* 组织文化的开放度

如果你所在的组织内的成员都抱有一个Open的心态，那恭喜你，你真是太幸运了。你的布道实践一定是相对顺利的。但实际情况中，大多数组织的文化可能没有 想象中的那么Open，大家对变化的第一反应就是"抵触和反感"– 好好的，为什么要变？你也可以说这是人的天性 – 习于安乐。显然在这种文化下进行布道，阻力将会较大，布道者需要做足准备，方可开始实施，即使如此也未必能取得很好的效果。

* 布道路线的选择

布道的路线无非两种：自上而下和自下而上。普通技术人员(包括一部分技术管理者)，多是自下而上，通过布道，说服项目组成员以及管理层使用新技术/新实 践。爬坡总是困难重重的，要想取得良好效果，需更多努力；技术管理者或其他管理人员可能采用自上而下的方式，告诉大家我们应该更换技术，采用新优秀实践， 多半相对顺利。如果你的技术的确解决了大家的问题，让大家平时的工作更"舒服"，自然就更受欢迎，推行起来也就水到渠成。

* 布道时机和对象的把握

变化是需要用成本买单的，既有人力成本，时间成本，甚至包括机会成本。如果你非要向一个下周就要发布的项目组推广JUnit，非要向一个工期仅有三个月且 交付后无需维护的产品线推广持续集成/交付，那你肯定是自找苦吃。这些例子都说明了一点：把握好布道的时机和对象。人家都忙得脚打后脑壳了，你还给人加添 乱，显然时机掌握错了；你推广的东西除了增加成本并未带来任何好处，显然对象选择错了。正如《布道之道》一书中提到的那样：你推广的成果(技术或工具)应 该可以让受众至少感觉到如下价值之一才行：提高了效率；降低了风险；增进了理解。否则你就找错了推广对象。

二、技术布道的有效实践

弄清楚上面的影响因素后，我们就可以谈谈一些利于收获良好结果的技术布道的有效实践了。

* 从问题出发，选择要布道的技术/工具

前面说过，你布道的成果(技术/工具/优秀实践)是需要给大家带来价值的，这其中主要的方面就是为了解决大家目前所面临的问题，比如开发效率不高、系统部 署繁琐、人工回归测试工作量巨大等等。因此只有当你觉察到这些问题，并对这些问题深入理解后，再去选择你要布道的技术/工具/最佳实践；否则如果只是为了 引入新技术而引入新技术的话，那么引入的技术和工具就好比无源之水、无本之木，没有长久的生命力。

* 选择合适的受众与时机

布道所推广的技术和工具多不具有普适性，它在一定受众范围内是有生命力的。因此在谋划布道之前就要考虑好对象。甚至可以在布道之前先深入到选定的受众当 中，对受众以及他们所遇到的问题进行相关的调查和分析，这样做才能事半功倍，布道的结果才可能更佳；另外在确定受众后，就是选择布道时机的问题了，时机的 选择因情况而异。但无论如何也不能犯上面提到的那些错误，否则你的努力将付之东流。

* 以点及面，划分阶段

受众面越大，布道的结果可能越不易理想。因此，最好先在小范围内布道并给予持续支持，直到该技术/工具/实践在小范围内变得不可取代并看到了成果，再向更 大的受众范围推广，此时之前那些已经尝到甜头的受众将会成为你下一阶段布道的强力助手。另外阶段性的布道还有助于你进行自我挑整，修正之前的不足，找到更 为合理的策略和方法。

* 利用局部布道成功结果的影响力说服更广范围的受众

人们都信奉"眼见为实"，因此将前期小范围布道的成功结果会让更广范围的受众相信你推广的技术/工具/实践将会给自己带来价值。这要比你口若悬河般的说教好上百倍。特别是在说服管理者时，这尤为有用，甚至决定成败的那个最重要的因素。

* 建立信心和耐心，潜移默化中布道，甚至先斩后奏

对于一些之前布道失败(无论是否是你推广的，包括那些被管理者否定的)的技术/工具/实践，只要你认定(在对问题的深入理解的前提下作出的判断)它会带来 价值，那就不要放弃，要有些耐心。并运用上面那条实践，先在局部尝试，影响小范围受众；收到显著成果后，再扩大受众面，用现有的成果说服他人，或甚至直到 当管理者问及你是如何取得这个成果时，你再告诉他：是因为我用了XX技术/工具/实践。

* 降低目标预期

最后这点算不上什么有效实践。对于布道者而言，如果要想保持一个持续向前的心态，保持持续关注前沿技术的动力，降低布道结果对你的负面打击，那就在布道之前降低你的目标预期吧。

最后切忌犯一个错误，那就是：只懂皮毛，就去布道推广(多数都并非出于解决问题之目的)。这样做的结果只能是失败，并很可能让大家失去对你的信任。这个错误自己犯过，见过职场新人犯过，也见过牛人犯过。