|
要是有朋友劝你写本书，无视他们吧！这样你就不用继续看下去了，很节省时间。 还在看？好吧，朋友，我想我得给点好的建议呢。我前几年曾经跟人合作写过三本书。在读博士的时候，我也写过很多技术论文和公开发表的文章。我就是个做苦差的人。 |
Khiyuan
|
1) 理解你要写的东西如果你在专注于写本技术书籍，你可能认为自己是这方面的专家。写书对于翻出话题中你所遗忘的部分，深入理解他们是一个很好的机会。通过向其他人说明的过程 来学习是一个很不错的方法。当然，这并不是说我们鼓励你把正在学习的东西写成书。很可能你写出的东西读起来很像总统候选人的宣言，只是谎言少点。 即使你了解一件事务，你也不见得明白解释给别人的后果。而着眼于主题书写大纲（见＃3）将比了解你的读者（见＃2），向他们解释更加困难。 |
Khiyuan
|
2) 了解你的读者谁是你的书的受众？他们了解那些内容？那些对他们来说是新东西？这些东西能够帮助你标识书写大纲时需要加入的额外材料。创建一个描述读者的角色可能会有所帮助。 例如，当我们编撰《C++ AMP book》时，我们觉得我们的读者应该对 C++ 和 STL 有了解，但不了解对 C++11 中的新特性。所以我们在第十一章和参考中添加了一些读者可能需要的额外材料。 |
Khiyuan
|
3) 要有大纲书的大纲列出了书的每个章节，这些章节包含了那些主题，类似示例代码这样的附带材料和粗略的页码统计。这将帮助你估计你需要面对的艰巨的任务的大小，鼓励你不要半途而废。 当然，只有白痴才会在没有大纲的情况下写书。不管你信不信，我们在撰写《C++ AMP book》时，并没有重视大纲，结果我们缺失了完本必须的数个章节。额，不得不说，这真的很痛苦。 |
Khiyuan
|
4) 写个示例先很多时候，技术类书籍其实就是在解释示例。 特定的编程书籍中都有示例或是相关的案例研究。 如果代码是很难理解，书中就得有所解释。 代码写的越好，你的额外写作就越少。 先写示例在再写章节，然后修改示例，让他们一致。 例如，你发现使用像“主/仆”这样的特定术语能够解释的更好。 不要犹豫，立即使用相同的术语，方法和变量名修改代码。 如何为撰书更好的编写示例代码将是另一篇博客，这根写好产品代码是两码事。我们可以以后在为大括号的位置吵几句。 将示例代码开源，将其按照章节拆开进行审查，并要求审查者反馈。当我用 Visual C++ 编写并行编程的示例时，我已经很久没用 C++ 了。 我很幸运，在发布之前，有 PPL, STL 和 MFC 的团队成员审查我的代码。 最后结果还不错，而我在其中也学到了一些东西。 |
Khiyuan
|
5）文稿检查即使是科幻小说作家，他们的早期文稿也是通过了各种检查的。严谨的技术书籍当然不能免俗。如果你拥有可以从你的读者角度阅读你的文稿的检查者，这当然是最 好的。他们可以给你一些反馈。你还应当获得一些专家的帮助，以保证内容的准确性。你也可以把部分文稿放到网上征求大家的反馈意见。有的出版社会雇佣一些人 来阅读书稿。但是我个人不喜欢这种方式，因为这限制了潜在的读者群和反馈。而且“阅读反馈.beta”并不能改善人们对你的书的印象。 尽可能多读读他人的评论。读书是要花费时间的，而读了书的人并不一定提供反馈。你一定要记住他们最多就给你提供一个确认（书好或者不好）。 |
王政
|
6) 审核回馈只是回馈 feedback is just feedback如果你获得大量的审核回馈（见 #5），你需要决定怎么处理它们。有时不同的回馈之间会有冲突。审核人员有着不同的观点和动机。有些人可能喜欢你的目标受众，有些人可能不会。有些人则可能热衷于所有的瑕疵都写出来，也有些人更倾向于批评。 所有的反馈应该解决，但是这意味着你需要考量它们并根据它们进行修改。 不用什么都听审核人员的，特别是你觉得对读者没有帮助的时候。 我可以想到很多我完全不会理会回馈内容的情形，我并不认为在同一人的回馈基础重写书中的部分内容能够更好的服务其它读者。 举行写作研习会也非常棒，当有读者像你解释它们对你所写的东西的想法时，你会觉得十分惊奇。 拉尔夫·约翰斯顿在伊利诺伊大学的学生提供了很多这样的反馈，它们对我们的C＃书非常有帮助。 |
Khiyuan
|
7) 找个好的编辑团队好的编辑就像好的测试人员一样。 开始的时候，我们都会觉得没有他们一样没问题。 当你第二次这么做时，你会觉得如果自己没有自作聪明就好了。 好的编辑人员和好的副本编辑工作能够让你的书更好。 编辑真的能够改善你的书的整体结构，并筛出前后不一的地方。 好的副本编辑人员对书的贡献不仅仅是能使得阅读变得更愉快。而差得编辑则可能弊大于利，甚至是出现错误。 跟你的编辑团队明确如何进行排版，特别是涉及到技术术语的时候。 我花了数个小时将代表 C++ AMP array<T> 的 array 改为斜体，并清除代表序列值的 array 的斜体格式。 将一个阳光明媚的周日下午花在这件事上，真心不让人愉快。 |
Khiyuan
|
8）确认你的进度写书这种事情很奇怪。他永远没有严格意义上的最后期限——除非你明白你这一章的推迟会导致进度表上什么样的波澜。而写书的“最后期限论”并不适用于书的出版。 很多出版商的图书出版管理采用承包制度，排版，设色等等工序都责任承包到人。如果被你鼓吹了好长时间的最后期限被打破，这意味着之前的努力全部流产。书本 发行的下一个工序由于你的原因不能及时启用。而发行图书的工序绝大多数都这样线性。排版被推迟，那么索引也就不能开始（这需要排版以后的具体页码），这又 延误了时间。好吧，一次小小的推迟就会造成书籍出版的大时段的延宕。 总之，如果你想要严格按照时间表来出书。理想条件下，你的发行团队应该经常性的提醒你，保证你清楚最后期限对大家意味着什么。当你由此引发的联想全是关于 什么：“附录A质量不高”之类的东西的时候，你就可以真正按照进度表来工作了。好的发行团队会不断提醒你这些东西，而坏的呢？他们告诉你我这周五只需要一 个梗概就可以了。 |
王政
|
|
9）认可你的团队 任何技术的书的最重要的部分之一是致谢部分。写这种书绝对是协作的努力，但所有的评论，编辑，艺术家和其他人的姓名的都不会出现在封面上。正因为这个出现在第8并不意味着它是名单上最后一个。我经常在最开始就写致谢部分以确保没有人被排除在外。 我很幸运，从伊利诺伊州大学，英特尔和微软研究院一直参与微软的产品团队合作并得到他们的评论帮助，你会发现他们会出现在每本书的致谢部分。 |
凡程子
|