转载

如何写一本技术书

2018年4月份，我接到了博文视点编辑的约稿——写一本爬虫相关的技术书籍。经过近一年的辛苦创作、编辑、等待，本书终于出版了。

如何写一本技术书

3月底拿到样书的时候，回忆起去年接到写书邀请时的纠结，再到写第一章时的痛苦，以及最后成稿后的释然，都觉得是一场珍贵的人生经历。这篇文章将会分享一些写书中的经验，希望对你有所启发。

前期研究

这是一本爬虫题材的书，市面上写爬虫的书林林总总，很多公众号也有爬虫的各种资料，我当时认为再写一本类似的书没有太大的意义。为此，我在选题之前做了几天的调查，将最近两年的爬虫书籍、一些公众号的文章拿出来进行了一些研究，发现这些内容都有一些共性：

大多数针对初学者，很多以0基础入门作为卖点
讲基础的部分太多，很多软件的安装方法、框架的使用其实已经包含在软件的文档里面，稍微有一定英语基础的程序员都能够掌握
案例讲解基本上到数据爬取完成就截止，但对于数据分析、可视化等数据的价值部分则没有多讲

针对这些不足，我想写一本以案例、思路分享为主的书，不再过多的讲解基础知识，而是将数据爬取、处理、可视化、分析等结合到一起，让读者有一个全景观。我认为这样的书对于初学者肯定有一定的难度，但对于已经学会了基本的爬虫、想提升一个档次的读者是有较高的参考价值的。

和编辑确认好了选题及基本的思路后，就开始整理书的素材。得益于不断的积累、经常性总结和分享，我有大量的博客和工程供参考，这些都是非常好的素材，否则从头开始写一本书是非常困难的。

在整理的过程中我发现，由于对方网站、APP的更新，爬虫的时效性是个非常大的问题，已经有一些爬虫无法工作，有些需要更改方案。这一点也在书中进行了明确，并且在写作上尽可能的对思想进行阐述而不是实际的做法，使得读者能够知其然、知其所以然。

案例的价值

在本书的架构上，我重新整理了案例，确立了书的整理框架和价值。

首先是以快速的基础导入为主，总结了爬虫的形式、数据源以及几种常见的反爬虫的方法。更重要的是，作为爬虫技术中重要的代理池资源，我将我所用的百试不爽代理池的方法进行了公开，以便读者能够以最低的成本获取最多的代理用于后续的爬虫开发。

在案例上，以共享单车为例，我发现对于高校师生和城市规划研究爱好者来说，可通过单车数据对城市进行多维度的研究。然而，互联网上能够找到的单车出行数据非常有限。2017摩拜单车官方通过数据竞赛的方式提供过部分数据，这些数据为研究者提供了非常好的官方数据来源，但由于数据所覆盖的城市有限以及时间的流逝，历史数据已经没有太多的研究意义。如何拿到最新的数据进行研究，是摆在研究者面前的最直接的问题。

如何写一本技术书

（图：某城市单车热力图）

如果仅仅想拿到一个时刻的数据，通过抓包就可以很快的获取。但如果要获取一个城市中单车位置的快照数据，对时间的要求非常苛刻（例如北京五环内5分钟之内），则是一个非常大的挑战，必须要进行爬虫的策略的调优以及技术优化，这对于爬虫初学者很难解决。再看一下爬取到的数据，每5分钟有40万左右的单车数据，那么一天的数据就有1亿条这么多，不太可能用excel进行处理。面对这么大的数据量，必须要选择合适的方法才能进行有效的处理，进而得出想要的结果。这些思路及方法就是放在非计算机专业人事面前一个较难解决的困难。对于数据分析的结果，可视化也是非常重要的环节。使用Python时通常会使用matplotlib进行可视化，另外我还介绍了web版本的轨迹可视化的方案，以便弥补matplotlib与地图集成的不足。

如何写一本技术书

（图：某单车推测的行车轨迹）

共享汽车、自由职业爬虫等案例也是遵循了类似的写作思路，但针对的目标更为复杂。面对APP可能有更复杂的数据获取方式，要获取到他们的数据，有一些技巧和方法。这些方法和正面破解的方式不一样，例如使用中间人(man in the middle)的方式截取数据。这种方式有一定的通用性，可以长期有效的运行。

如何写一本技术书

（图：通过中间人方式截取数据）

最后，书中通过一款机票历史价格查询及预测产品，讲述了一款数据产品开发时候需要遵循的一些方法。

如何写一本技术书

（图：一款数据产品开发）

用好工具

开始正式写作，要选择好一个好用的工具，常见的工具有：

Word：相对比较容易掌握，所见即所得，但较难进行版本管理。
Markdown：程序员用的较多，纯文本，有很多可视化工具，方便进行版本管理。
Latex：科研论文用的较多，纯文本，能够做出很专业的文档，但学习成本、配置成本较高。

为了减少工具对写作的负担（包括录入、调整格式等干扰），平衡了利弊后选择以Markdown作为初稿的编辑工具。当初稿写完需要进行排版的时候，再提交给编辑一个Word文章进行后续的编辑。

一本书大概有30万字左右，会分为多个章节。大多数人都会拆成多个章节来处理，每个章节一个文件。但我尝试了一下发现，单一Markdown文件就非常利于管理：

方便预览整书情况
方便章节之间相互引用
方便导出

在工具的选择上，我在Visual Studio中安装了Markdown Preview Enhanced插件，这个工具很好：

自动预览
自动生成目录
自动内嵌图片、内嵌代码
能够导出成多种格式（Word格式、PDF格式等）

对于一本需要引入大量代码的文章来讲，代码的正确性是很重要的。在这个插件中，增强的Markdown语法中中可以直接引用代码。这样我更改了代码以后，书中的代码也更新了，避免了不同步的问题。

整本书从头到尾都是用Git管理的，这也是程序员标准的工具，就不用多说了。

如何写一本技术书

（图：使用Markdown编辑书籍）

迭代交付

迭代交付在敏捷项目的成功中扮演者很重要的角色。写一本书也可以使用迭代交付：每一个章节作为一个迭代，每个迭代大概一个月左右。从开始写作开始，一鼓作气，坚持每天花时间写，避免拖拉。每个迭代完成后，将写好的文稿第一时间给编辑进行预览并提出修改建议。

在迭代的交付过程中，针对本书的性质，还是做了一些相应的修改以符合法律法规的要求。比如原书中有一些地图相关的图片，在2018年国家新的地图管理中，地图是必须要相关机构审核才能在书中出现的。为了避免审核的时间消耗，我对有相关图片的内容进行了一定的删减。得益于迭代交付，在书稿早期，就对内容进行可刻意的控制，避免了大规模返工的情况。

如何写一本技术书