如何写一本技术书籍

想出任 CTO，赢取白富美，走上人生巅峰吗？

靠写技术书，那是不可能的！

TL;DR;

• 写书不赚钱 。越入门的书销量越好越赚钱，当然了作者越容易被吐槽。
• 阶段 0 ：了解出版。了解为什么要写作，以及对应的出版流程：1. 确认主题、2. 约稿合同、3. 写作、4. 编辑与校对、5. 出版合同、6. 出版发行。
• 阶段 1 ：准备。收集该技术领域资料，选定技术主题和方向，确认出最后大纲。
• 阶段 2 ：沉睡。让大纲沉睡一会儿，让自己冷静冷静——是不是真的要写，改进书籍的大纲，并制定一个写作计划。
• 阶段 3 ：动笔。寻找合适的写作、绘图工具，规划好每天的写作时间。
• 阶段 4 ：校对与出版。

前言：写书不赚钱

写书是一件性价比特别低的事情。你要辛辛苦苦劳动几个月，才比得上隔壁老王半天的知识付费的收入。

一本书的稿费一般在书价的 8%~12% 左右。我的三本书都是 8 %，以 69 元 卖出 4000 册来算，再加上 12+% 左右的税，到手不到 20k。而且，稿费一般是要等书出版一段时间之后，才能拿到第一部分（首次印刷册数的一半）。

当然了，若是写的是某门语言，某个框架的实践手册，那销量可是更好了。并且，它们的写作成本相当的低，可能用上半年的时间，就能写上好几本。有些直接搬官方的示例代码，有些还会复制官方的使用文档。更不用说，很多这一类的书都是由多个人共同编写的。框架类的书，出书的速度越快，就越能获得大师

对于一本书的作者来说，每本技术书至少都要花上半年左右的时间和精力。因为我不加班，所以时间上会稍微短一些。若是那些 996 的公司，比如狼叔，写书的时候是 Node.js 8，出版的时候已经是 Node.js 12，笑~。

而现在流行的知识付费呢，对于作者来说，能拿到的收入都在 50% 左右。一门 99 元的课程，作者可以拿到 49.5。花上两三个月的时间，卖上 1000 份左右，那就比。虽然，大部分（少部分还是相当不错）的知识付费内容质量堪忧，但是它们还是相当赚钱的。

既然，这样为什么我们还写书呢？

阶段 0：了解出版

写书，真的是又累又不讨好。

WHY

为什么写作呢？名 or 利？

以前，年轻的时候，我是一个文艺青年，想去写自己的~~文学书籍~~——无奈文学水平不够，只能写技术书籍。一本书，除了向~~向我的子孙后代炫耀~~，还可以感动自己。所以，当我拿到第一本书的时候，有那种喜极而泣的感觉。

对于现在的我来说，学习，重于名，也重于利。

• 总结。一本技术书籍可以连接所有的片段。我在 GitHub 开源的电子书也是如此。连接所有的片段，形成自己的知识体系。这是一种能力，介于学习与总结之间。并且，我从中获得大量的新知识。避免碎片化，传承知识。
• 传道。分享软件开发经验，以来帮助开发人员构建更好的软件系统。
• 影响。改变人的思想和行为，让他/她们变得更好。
• 赚钱。与纯写书的收入相比，赚得更多的是围绕在知识周围构建的——软件开发、咨询、粉丝经济、广告费。

为什么会有人读书？

• 阅读思考的稀缺。思考的人越来越少了，阅读的人越来越少。人们渴望快速得到答案。
• 学习的持续性。
• 技术书籍的价值。你买的知识付费的内容是你的吗？？不是，平台关了，内容删了，一切都没有了。

WHAT

写书是一个持续性的体力和脑力活动，构建出围绕某一特定主题的学习内容。

每天利用自己下班之后的业余时间，看着男/女朋友在床上，只能默默地继续码字，而不能睡一个懒觉。平时，也抽不出多少时间去玩游戏，还有看电影的时间也变得需要考虑一下。

HOW

出版的流程，一般分为这么几步：

1. 确认主题
2. 约稿合同
3. 写作
4. 编辑与校对
5. 出版合同
6. 出版发行

我的模式通常是：

1. 写作
2. 出版
3. 校对
4. 发行

这适合于现今的模式，因为除了纸质书籍，还有其它方式，诸如于开源电子书，知识付费等方式。

出版合同

和出版社签定合同的时候，有两种合同：

- 约稿合同。即：出版人在著作人尚未完成作品，甚至还未开始写作的情况下双方就预约稿件而达成的协议。

• 出版合同。即：著作权人将作品交付出版者出版，出版者依法支付报酬的协议。

下图分别是我之前的书的约稿合同和出版合同。两个合同之间的时间，主要就是创作的时间。

如何写书 -> 阶段一：准备

阶段一的结果产出物：

1. 一个明确的书籍主题。不应该是后端相关的，而是详细到具体的内容，如 Spring 微服务
2. 一个详细的大纲。后期写作的时候，只需要根据大纲来填充内容即可。

这个阶段是： 发散 -> 收敛 的过程。先由主题去寻找可能的资料，再收敛到大纲中。

确认主题

主题，并不是一件容易的事。早在 2017 年初，我编写电子书《我的职业是前端工程师》的时候，便想写一本类似的书籍，可是没有找到一个好的突破点。

可等电子书的系列文章结束之后，虽然在豆瓣上和知乎上的反馈不错，可惜我想不出这样的书，是否有出版的必要。一来，我不是一个可以卖工作经验的老人，二来，我想不出对于读者来说，会有什么收获。

从那时起，我假设了三本前端相关的书，直到动笔之前的日子里，才领悟到。啊哈，我可以写一本这样的书籍，总算是没有白费时光。

选定稀缺的主题

我的第一本书《自己动手设计物联网》，除了是本入门级的书籍之外，它还是市面上最早的物联网相关的实践书籍——因为我毕业的时候，在写毕业论文找不到合适的内容，便将相关的论文发表在网上。刚好出版社看到了，便有了一个约稿，也因此有了第一本书。

不要重复主题

也因此，市面上第一本框架相关的书最好卖了，你再写第二本很难撼动他们的地位。如果你真的有一个相关的话题，请出门左转，找另外一个出版社——每个出版社，都会尝试去覆盖每一主题。同一个出版社，不会有出同一主题书籍的想法。

当然了，如果是市面上只有国外翻译到国内的书，那么国内也需要同样的主题。所以，这算不上是一种重复——“我大清自有国情在此”。

入门级还是？

越是入门级的书，则越容易有销量。

我的第一本《自己动手设计物联网》，总印数 6800 ，销量不到畅销书的水平（10000 本）。不过，因为是第一本书，所以有了繁体版的~。我花费大量时间写的 第二本《全栈应用开发：精益实践》，但是反馈一般。我的第三本书，《前端架构：从入门到微前端》问津的人可能就更少了。

越是有逼格的书，销量要起来并不是那么容易的一件事。

资料收集

我们需要从 Google、GitHub、技术社区、微信群等，收集相关主题的常见问题。开发人员在开发的过程中经常遇到的问题，或者将要遇到的问题，越是有写作的价值。当然了，如果只写相关的问题，那也是不行的。

搜索相关的问题，以 Serverless 为例，可以搜索：

• Serverless
• WHAT Serverless
• Serverless pros cons
• Servleress problems
• 等

而后，一点点地补充相关领域的大纲。

确认大纲

写一本书的大纲真的很难——因为写完大纲的时候，你相当于已经在心里把这本书写完了。它涉及到你要在书中写的所有内容。哪怕是有了多本书的经验，要一次性地就确认出大纲，也不会是一件容易的事。

与此同时，大纲讲究的是：循序渐进，章节之间存在一定的关联性。书的内容要深入浅出 or 九浅一深，也意味着大纲要展示出这样的部分。

大纲示例

假设，我们要写一本 Serverless 相关的图书，那么我们需要这么几部分的内容：WHY-WHAT-HOW

• 趋势和概念介绍
• 相关的框架和工具
• 相应的设计模式
• 实践案例
• 总结

接着，更细致的去划分原来的目录结构，如概念部分，进一步往下细分：

• 为什么选择 Serverless
• Serverless 是什么
• Serverless 能做什么
• Serverless 的优缺点
• Serverless 相关的实践
• ……

如何写书 -> 阶段二：沉睡

你需要休息上半个月，一个月，再继续写书之旅。这个时候，要做的有这么几件事：

• 考虑一下，是不是真的要写一本书。
• 制定一下写作计划
• 收集灵感，改进大纲

真的要写吗？

罗列完大纲的你，一定已经很累了——你可能是拿平时玩游戏的时间、看电影的时间、休闲时间来做这样的一件事情。

所以，你还有机会思考一下，你是不是真的要去写书？

你能从中又获得什么东西呢？

写作计划

什么时候开始写？什么时候写完？

每个月的进度是多少？

每个星期的进度要多少？

每天都写多少？

如果目录拆分得够细，从一级目录到四级目录，大概可以一星期一章，一个月四章（以我这种不加班的时间来算）。那么三个月，大概能完 12 章，外加 1~2 个月的重新校对和排版时间来算的。大概 5 个月就可以写完一本书。那么，以一本书 20 万字的规模来算，一章大概是要 2 万字左右， 也就是平时每天大概要写下 2000~3000 个字，周末再补上 5000~1000 字。不过，这种算法是不对的，一个大章节大致上可以拆分为 4~N 个小节，每天写个一小节就差不多了。

收集灵感，改进大纲

在沉睡期间里，最有意思的莫过于，你在日常写作的时候，会迸发出各种各样的灵感。这些灵感，你会考虑把它们都加到书中去。

而这种改进的来源有多种多样的：

• 项目实践
• 技术文档
• 其它技术书籍

你还可以与其他/她的技术大佬讨论，与获取一些更好的意见和建议。

如何写书 -> 阶段三：动笔

在写作的过程中，你的自律能力会不断地提高——直到你仿佛到了一种机械的状态。而这种状态，会让你忘记掉时间——没错，这就是心流。自律，依赖于目标，依赖于你的欲望。自律，对于我来说不是一件痛苦的事。每天按时起床，对于我来说，反而对于我的身体来说是一件好事。

动笔的时候，无非就是：

• 寻找合适的写作、绘图工具。=
• 通过 Deadline 来驱动写作
• 规划好每天的写作时间
• 写好细致的示例代码
• 管理好你的情绪周期

工具

写作的工作有各种各样的，对于我来说我用的是：markdown + Git + Phodit —— 自豪地采用自己编写的 markdown 工具 Phodit 作为我的编辑器，我在写这篇文章的时候，也是用这个工具，哈哈哈。采用 Git 作为版本管理工具，方便我随时进行回滚，以及进行各种统计。

对于有些出版社来说，它们采用的是在线 markdown，有一些出版社则接收的是 Word。所以，在你采用 工具 之前，先了解一下最后的格式。但是，我建议使用： 可以分布式协作的版本管理平台 ，诸如于 GitHub。毕竟，程序员可以高效地使用 程序员 的工具。

绘图工具

在写作的过程中，难免会插入流程图等各种东西。诸如于 Visio 就是一个不错的工具，但是我用的是 macOS，我也没买 Visio。以下是我的绘图工具，从简单到复杂的模式，有：

• Word：Office 的 Smart Art 带了一系列丰富的已知图片样式。
• Keynote：方便于创建分层架构。
• Sketch：创建自定义的高级图片。

Office 和 Sketch 都是要钱的，这些专业工具是真的贵。

deadline 驱动写作

我的第一本书，大抵还是犯了进度的错误，截止时间（deadline）给我带了一定的压力。在内容的构思上，便是没那么长，也导致了我每天有一种紧迫感。所以，写的时候就会有一种赶稿的感觉。

在我的第二、三本书，便是先写完再找出版社，毕竟写书的人少了，到底还是可以找到些愿意的出版社。它的好处是构思的时候，可以更加自由。可是呢，在写作的时候，我也没有那么急了。缺点是，它依赖于你的自律能力。与此同时，你还面临找不到出版社的风险。

时间规划

进入写作时期的我，一般会呈现一个规律的写作周期。从周一到周五：

• 早 40 分钟： 7:10 ~ 7:30 + 7:40 ~ 8:00
• 中 30 分钟：12:30 ~ 1:00 / 1:10
• 晚 ~60 分钟：19:40 ~ 20:55（不含周五晚）

周末：

• 8:20 ~ 11:00 有间隔，每小时大概只写 30 分钟。

每天起床到准备去公司上班，总是能有个半个小时或者一个小时的时间，让我补补昨天的大纲。中午因为有午休时间 ，又多了半个小时的时间。至少晚上嘛，不加班，时间多，从六点半到十点的时间里，还是能凑合着挤出两个小时。

这样一算吧，每天还是能写下三千个字，只是以往写代码的时间变少了。每次在前期的时间，总在纠结，“要不咱不写这本书了”。写书的过程中，遇到上麻烦的示例，便开心的回去继续写代码了。到底，还是一个程序员。

写起东西，并不会那么顺利，写上个二十分钟、半个小时，总得休息一会儿，活活动动，然后才能接着往下写。

哪怕是有时间不想写，也得挤挤一些字词，方便明天进行写作。

到了周末，我又会到这些东西忘掉。

示例代码

除了书相关的内容之外，为了配合好读者的学习。经常要写上大量的代码示例，而后选出那些特别适合于读者理解的。有时候，花在一个章节的示例上的时间，远远比写这一章节的时间要长。它也可能影响到这本书的进度。

根据写的内容，不断地改进示例。甚至于你在写第四章的内容时，因为不能循序渐进，你还会回过头来修改第三章的内容，以及匹配的代码。以至于，有时候，你可能想将错就错下去。只是呢，专业性会让你回过头去，把那些内容改好。

情绪周期

刚开始写作的时候，难免会很兴奋，写起来那也是相当的快。只是作为一个人，我们还是存在明显的情绪周期。写一段时间（两三星期）之后，我们便很容易陷入低潮。在这个低潮期里，我们会抱着一些负面的想法，以至于我们可能会动摇信心：是否继续写下去？

但是呢，只要慢慢继续往前走，我们就又会回到充满信心的阶段。然后，往复循环，哈哈。

如何写书 -> 阶段 3.5：注意事项

短的段落、句子

段落和句子不宜过长。过长，一来不容易阅读，二来，会让读者失去继续往下读的动力。

应对词穷：阅读非技术书籍

写书的过程中，对于我言，遇到的最大挑战是词穷。技术书籍，充斥着各种因果关系的描述：

因为……所以…… 尽管……，但是……，因此

还有各种先后的顺序：

首先……，然后……，接着……，结果…… 接下来……

一旦上一个段落用了其中的一个句式，那下一个大段落就惨了。若是再采用同样的句式，怕是对读者不好交待。

因此，在写作的时候，我往往会阅读一些文学类的书籍，以适当地增加我的词汇量。与此同时，改进一些不好的写作模式。

代码还是内容

没有代码的技术书，要理解起原理就不是一件容易的事。代码太多，则容易被吐槽。因此，一些无必要的代码是不应该出现在书中的，必要的代码要在书中展示。所以，这也不是一个容易的工作。把握好两者之间的尺度，并不是一件容易的事。

我的前两本书是新手向的书籍。第一本书里，充斥着代码；第二本书里，因为有第一本书的反馈，截图多了一些，代码倒是相对少了。可到了第三本书，但是开始面向中级的软件开发工程师，还使用老套的方式，怕是又要被批评了。批评总会有，资深的程序员，少些代码粘贴，多些解释，剩下的内容都扔到 GitHub 上了。

文字和图片的版权

作为一个创作者，若想别人尊重我们的作品，我们也必是要尊重别人的作品。引用别人的文字，需要标明出处。引用别人的图片，也需要标明出处。

除此，对于出版社来说，还有一个网络查重的过程，你需要保证 99% 所有的内容都是你原创的。不应当去抄袭和复制别人的作品。

如何写书 -> 阶段四：后续

待续……