胡百敬,具MCT、MCAD、MCSD国际认证执照。并获选为微软“最有价值专家”MVP(Most Valuable Professional)。现任台湾恒逸资讯资深讲师、微软专业顾问、联合报系技术顾问。拥有多年系统分析、设计与实际经验。曾参与许多大型项目开发,主讲微软台湾全省百场以上大型研讨会,同时也是一位活跃于IT媒体的专栏作家。
半年多前,胡百敬老师在Blog中写了一篇文章《撰写信息书籍注意事项》,其中给出了若干条言简意赅的指导意见。看到目前园子里很多朋友正在准备撰写/翻译技术书籍,Dflying希望能够和大家分享一下这几条意见,并总结自己的实际写作经验加上一些心得体会。(以下粗体部分为胡百敬老师的原文)
名声第一,利益第二,不要在别人案头留下骂名。
之所以在第一条就提到了这一点,是因为这是个态度问题。不可否认,对于某些朋友来讲,写书是创造财富的一条行之有效的道路,特别是那些胡拼滥造之作,一个月就可以写出一本——网上搜索一下代码、文章,甚至连调试都没有调就这样写了出来;或者是长篇累牍的代码,从到一字不少;更有甚者直接引用大段的官方文档……
自己的名声,要一点一滴的珍惜。书籍一旦出版,就像刻在了石头上,可能流芳百世,也可能遗臭万年。动笔之前,先端正我们的心态。
书籍定位清楚,没有适合所有人的书。
很多朋友,包括我在内,在第一次写作的时候都喜欢长篇大论,非要事无巨细将所有东西都涵盖才好。然而贪多嚼不烂,不要妄图写出百科全书——即使要写百科全书,也不会是你的第一本书。现在软件开发都讲究敏捷,小迭代,写书的时候难道不也应该参考一下么?太多太长,主题往往淹没在滚滚文字中,难免最后样样通、样样松。
章节目录由简而深,必要内容放在前面章节,选择性内容放在后方章节。
这一点是人之常情,符合人类(即使是动物也如此)的理解习惯,没什么好说的。最完美的就是,某一张开始承接上一章,结尾引出下一章。
第一章最后写。
第一章往往起到统领全书的作用:若是介绍一个框架,那么这一章就将大概把框架的特性,结合本书所讲的内容列出来。若是介绍语言,那么则会逐一阐述语言的特性、历史、发展等。若是开始的时候就写第一章,那么难免随着写书的过程不停地修改、调整,造成不必要的时间浪费。
我在撰写《ASP.NET AJAX程序设计》一书时,就是没有经验先写的第一章。刚刚察看了版本控制系统,这一章已经有了奖金200个版本,几乎每天都要修改……比较一下最初版本和最终版本,早已面目全非……
不要有漫画书的状况出现。在图与图间最好加一些引述,说明。否则书会像漫画书,读者不容易连续想象图文之间的关系。
每一张图示都要在正文中有所提及。每一张图示的说明都要表达明确的意思,不要写“图3 代码3-4的运行结果”,而要写“图3 将XXX属性设置为YYY之后,页面将显示ZZZ”。还有,珍惜读者的¥或$,只添加必要的图示和代码——这两者非常占版面。
具体不要抽象,分析比较不要批评。
在比较的时候,不要简单地列出一个表格:A高、B低、C一般……要具体地分析出是什么造成了这样的结果。
参与比较的各个项目,往往在某些领域、某些时期都有独到的优势,很难说出谁就一定比谁好。所谓萝卜白菜,各有所爱,特别是针对不同平台、框架的比较,更要格外小心,力求保持中立、客观。若是一本讲.NET的书中不停地带有诋毁Java的词句,那么相信谁都不会愿意看。
不要中英混杂,每小节第一次引用的术语,英文连同中译一起出现,以后仅出现中译。
很多朋友在实际工作,或是在写Blog的时候经常喜欢中英文混杂,当然我不是批评这样的用法。但毕竟图书——白纸黑字印出来的——需要体现严肃性。“写code的时候不test,checkin了之后build break你才后悔”——这样的话万万不能出现在书稿中!
但对于某些专业词汇,特别是在翻译时遇到的中文译名不是那么流行或是有争议的词汇,则在括号中保留原词不失为一个好办法。如果可能,在书中还要给出统一的关键词翻译参考,要是能够顺带解释一下为什么选择这种译法,那就更是锦上添花了。
引用在线说明时,要小心 Review 其内容,一般翻译错误很多,最好能参阅原文在线说明。
这一点比较明确,就不再多说了。不过要提及的是,引用任何非原创的作品都要得到明确的版权许可,以免日后带来不必要的麻烦。
翻译时,注意中英文习惯不同,少用定冠词(如“一个”),人称代名词(你、我、他),被动式。尽量「意译」,而不要「直译」。
特别要提到的尽量避免被动语态,中文很少很少使用。
说到意译,更要把握好不同文化之间的差异,有些外国人都看得懂的俗语、或是他们文化中的幽默,中国读者却根本摸不到头脑,这是一定要加上足够的译者注,或是干脆用中国的等同故事替代。
补充一条:英文中的长句子,特别是定语重句一定要拆开,不要让人看到译文之后都能联想到原文。
每日要有习惯性产出,脱稿是从第一天开始,不要妄想赶进度。
坚持——这是写作中最重要的一条。写书不是写Blog,心情好我就一天一篇,甚至一天几篇,心情不好我就一个月都不管。写书讲究的是涓涓细流,积少成多。人都是很懒的,都会为自己找到很多借口,有了第一次脱稿,那么就会有第二次,第三次……好比一个函数有几个间断点没什么问题,但要是间断点太多,就不可积了。若不是对你的毅力非常有把握,那么最好把你预先计划的撰写时间乘以二!
写完一章后,隔些日子重读内容,务求文字精简,图像精致。
慢工出细活,一点都不假。不要写完一章马上开始校对,等过了半个月再重新来看,你会很快发现自己当初的幼稚……
文笔是苦练出来的,没有浑然天成。说话与写作是两回事。
多看书,多看技术书,看看人家是怎么写出来的。把代码写好并不等于能把书写清楚,把牛皮吹破也不见得下笔就有神。
找个有经验与耐心的人审稿。
书写完了,还要留一点时间给别人看看。一个人的能力总归有限,错误、误解都是在所难免,要不写代码的时候怎么要Code Review呢?