Blog

Blog

PHODAL

如何写一本技术书籍

想出任 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% 所有的内容都是你原创的。不应当去抄袭和复制别人的作品。

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

待续……

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《前端架构:从入门到微前端》

《前端架构:从入门到微前端》是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前端工程师更好地进行系统设计。

前端架构包含以下五部分内容:

  • 设计:讲述了架构设计的模式,以及设计和制定前端工作流。
  • 基础:通过深入构建系统、单页面应用原理、前端知识体系等,来构建出完整的前端应用架构体系。
  • 实施:通过与代码结构的方式,介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
  • 微前端:引入6种微前端的概念,以及如何划分、设计微前端应用,并展示了如何实现这6种微前端架构。
  • 演进:提出更新、迁移、重构、重写、重新架构等架构演进方式,来帮助开发人员更好地设计演进式架构。
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签