如何写三本技术书籍

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

靠写技术书,那是不可能的!前端

太长不读版

  • 写书不赚钱。越入门的书销量越好越赚钱,固然了做者越容易被吐槽。程序员

  • 阶段 0:了解出版。了解为何要写做,以及对应的出版流程:1. 确认主题、2. 约稿合同、3. 写做、4. 编辑与校对、5. 出版合同、6. 出版发行。算法

  • 阶段 1:准备。收集该技术领域资料,选定技术主题和方向,确认出最后大纲。后端

  • 阶段 2:沉睡。让大纲沉睡一下子,让本身冷静冷静——是否是真的要写,改进书籍的大纲,并制定一个写做计划。设计模式

  • 阶段 3:动笔。寻找合适的写做、绘图工具,规划好天天的写做时间。微信

  • 阶段 4:校对与出版。markdown

前言:写书不赚钱

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

一本书的稿费通常在书价的 8%~12% 左右。个人三本书都是 8 %,以 69 元 卖出 4000 册来算,再加上 12+% 左右的税,到手不到 20k。并且,稿费通常是要等书出版一段时间以后,才能拿到第一部分(首次印刷册数的一半)。前端工程师

640?wx_fmt=png

固然了,如果写的是某门语言,某个框架的实践手册,那销量但是更好了。而且,它们的写做成本至关的低,可能用上半年的时间,就能写上好几本。有些直接搬官方的示例代码,有些还会复制官方的使用文档。更不用说,不少这一类的书都是由多我的共同编写的。框架类的书,出书的速度越快,就越能得到大师架构

对于一本书的做者来讲,每本技术书至少都要花上半年左右的时间和精力。由于我不加班,因此时间上会稍微短一些。如果那些 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. 发行

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

出版合同

和出版社签订合同的时候,有两种合同:

  • 约稿合同。即:出版人在著做人还没有完成做品,甚至还未开始写做的状况下双方就预定稿件而达成的协议。

  • 出版合同。即:著做权人将做品交付出版者出版,出版者依法支付报酬的协议。

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


640?wx_fmt=jpeg

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

640?wx_fmt=jpeg

阶段一的结果产出物:

  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 相关的实践

  • ……

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

640?wx_fmt=jpeg

你须要休息上半个月,一个月,再继续写书之旅。这个时候,要作的有这么几件事:

  • 考虑一下,是否是真的要写一本书。

  • 制定一下写做计划

  • 收集灵感,改进大纲

真的要写吗?

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

因此,你还有机会思考一下,你是否是真的要去写书?

你能从中又得到什么东西呢?

写做计划

  • 何时开始写?何时写完?

  • 每月的进度是多少?

  • 每一个星期的进度要多少?

  • 天天都写多少?

若是目录拆分得够细,从一级目录到四级目录,大概能够一星期一章,一个月四章(以我这种不加班的时间来算)。那么三个月,大概能完 12 章,外加 1~2 个月的从新校对和排版时间来算的。大概 5 个月就能够写完一本书。

那么,以一本书 20 万字的规模来算,一章大概是要 2 万字左右, 也就是平时天天大概要写下 2000~3000 个字,周末再补上 5000~1000 字。不过,这种算法是不对的,一个大章节大体上能够拆分为 4~N 个小节,天天写个一小节就差很少了。

收集灵感,改进大纲

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

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

  • 项目实践

  • 技术文档

  • 其它技术书籍

你还能够与其余/她的技术大佬讨论,与获取一些更好的意见和建议。

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

640?wx_fmt=jpeg

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

动笔的时候,无非就是:

  • 寻找合适的写做、绘图工具。

  • 经过 Deadline 来驱动写做

  • 规划好天天的写做时间

  • 写好细致的示例代码

  • 管理好你的情绪周期

工具

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

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

绘图工具

在写做的过程当中,不免会插入流程图等各类东西。诸如于 Visio 就是一个不错的工具,可是我用的是 macOS,我也没买 Visio。如下是个人绘图工具,从简单到复杂的模式,有:

  • Word:Office 的 Smart Art 带了一系列丰富的已知图片样式。

  • Keynote:方便于建立分层架构。

  • Sketch:建立自定义的高级图片。

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

deadline 驱动写做

个人第一本书,大抵仍是犯了进度的错误,截止时间(deadline)给我带了必定的压力。在内容的构思上,即是没那么长,也致使了我天天有一种紧迫感。因此,写的时候就会有一种赶稿的感受。

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

时间规划

进入写做时期的我,通常会呈现一个规律的写做周期。从周一到周五:

  • 早 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:注意事项

640?wx_fmt=jpeg

短的段落、句子

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

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

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

由于……因此…… 尽管……,可是……,所以

还有各类前后的顺序:

首先……,而后……,接着……,结果…… 接下来……

一旦上一个段落用了其中的一个句式,那下一个大段落就惨了。如果再采用一样的句式,怕是对读者很差交待。

所以,在写做的时候,我每每会阅读一些文学类的书籍,以适当地增长个人词汇量。与此同时,改进一些很差的写做模式。

代码仍是内容

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

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

文字和图片的版权

做为一个创做者,若想别人尊重咱们的做品,咱们也必是要尊重别人的做品。引用别人的文字,须要标明出处。引用别人的图片,也须要标明出处。

除此,对于出版社来讲,还有一个网络查重的过程,你须要保证 99% 全部的内容都是你原创的。不该当去抄袭和复制别人的做品。

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

640?wx_fmt=jpeg

待续……

对,这就是在宣传个人新书。