作者：董伟明
链接：https://zhuanlan.zhihu.com/p/22207407
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
在过去的8个多月的时间里面，我完成了一本504页的《Python Web开发实战》。本文就是写这本书的一些感悟和心得，如果你准备写一本书（无论是出版社约稿还是想放在Github开源），希望本文对你能有一些帮助。如果你准备购买本书，也希望你能看到成书背后的一些故事。
--- 2016.11.10 插播 ---
这本书已经确定将输入到台湾
--- end ---
写博客 vs 写书
我从2010年开始写「技术博客」，到现在已经6年了。博客记录了我技术成长中的一些值得分享的经验，一方面希望惠及其他人，一方面作为一个连Evernote都不用的人，得有个平台记录这些技术笔记方便日后查看。首先我先承认博客写的并不好，主要原因是我的博客写的不够通熟易懂、深入浅出，我个人也不太愿意掰开了、揉碎了地讲的非常细致，在很多细节上是故意留给读者思考的空间。为什么这么做呢？因为我之前也喜欢「拿来主义」，看完之后觉得写的非常好，懂了，可是一段时间后就忘记了，我想这是因为这不是自己思考的结果，所以印象不会太深。我不太愿意帮这种倒忙。
我不做知识管理，脑袋里放了好多理解、经验，可是并没有系统的梳理过，写博客时候没关系，反正选题的内容窄，主题明确，写起来也会比较随意，理解不深或者理解错误也不会造成多大的损失，最多把博客改一改嘛。
写书完全不一样。
写书则得把握全书的基调，清楚书的结构，还得完全想好要表达给读者什么。我希望尽可能的深入细节，让读者看完就懂，原来那些比较模糊的细节要尽力的去搞懂，否则书出版了可就后悔不得了。这对我是极大的挑战，因为写博客的习惯改起来非常不容易，还得花费大量的时间去验证之前不确定的那些技术点，有些已经觉得理解了的技术点也得反复验证。
如何确定章节
在一开始，我花了一周多的时间在思考在书中要放什么内容，后来基本上自己已经清楚章节的安排，以及我希望传达给读者的方式。但是，这只是我所想的。
看过一本叫做《你以为你以为的就是你以为的吗》的书，它教会了我反思自己，对自己产生更多疑问。我当然希望覆盖更多的读者，但是我并不知道读者们的痛点有哪些，他们更想获得那些我熟悉的内容。我先发了篇博客，有同学留言或者同其他渠道告诉我一些诉求，感谢。我有一个人数5百多的QQ群，一个两百多的微信交流群，还有一些圈内好友的小组织，所以有段时间我经常在里面骚扰大家。问题无外乎2种：「你希望在书中看到哪方面的内容？」和「以你的经验，那些内容是必要的、有意义的？」。通过反馈，整书的轮廓就是这样慢慢显现出来了。和我之前想的还是有很多不一样的地方，举几个调查的结果：
1. 大家对爬虫、并发编程的热情最大。所以一本Web开发方面的书里面，竟然包含了一章「Python并发编程」。当然，Web开发者也是需要并发编程能力的。
2. 大家对产品运维的过程都希望有一些了解，所以书中对Fabric、SaltStack和Ansible都进行了较深入的介绍。
3. 我之前对「测试和持续集成」和「网站架构」等章节安排了比现在多很多的内容，但是大家的反馈看来并没有多少热情。
4. 大家对Python语法，编程技巧等方面热情也很大，但是受限于本书的选题和篇幅，只放了一章「Python进阶」。
我是这本书的舵手，我会听取反馈意见，但是无法满足所有的人的需要。如果书中的内容都面面俱到，由浅入深，我想三千页也讲不完，就像一位作序的老师说的，其实书中每章都能单独成书。
写这本书对我而言，最大的遗憾就是无法满足所有人的口味。就像编辑说的：「如果一本书可以解决所有问题，我们还怎么吃饭？」我把这本书的受众定位给有一定Python经验的开发者，其实本书不算难，讲的内容也算是互联网环境中的标准解决方案，太偏的，大家用到的机会少就不放进书中了。
控制篇幅
我曾经调查过页数和购买欲望的关系。有一小部分人觉得书太厚了就有畏惧情绪。大部分人觉得无所谓，只要内容认可就好。对我个人而言，我买书基本上是因为看目录中有我一直想了解的或者之前了解的不深刻的内容，积累到我认为性价比合适了就买，通常这本书的其他章节只是简单的翻翻甚至不看。我和编辑的共识是不要超过500页。一则这个选题以我之前看其他书籍的经验，基本就是这么个页数了；再则书厚了价格也要上去，对读者是一种负担；我和编辑都不喜欢拖拖拉拉，我也不靠写书挣钱，所以一开始的页数就是这么权衡出来的。
一开始列了一个大纲，列出了每个章节名字，以及预期这章节要写多少页。这里有个坑儿，Mou编辑器是左边编辑源文件，右边显示渲染后的效果，这个页数不是实际出版的页数，而是转化后的页数。写完一节就把真实的页数记录到大纲中，心里有个数。但是写完第七章之后，我就意识到按这个速度，肯定最后要超500页。所以从第八章开始，对页数控制的更严格，也做好了最后排版删除内容的准备。等写完之后，不出所料，第一次把书稿按照某本已出版的书的格式转化成pdf，页数为640页。
也就是说，为了控制篇幅，我要开始删除一些章节了。删除怎么安排的呢？
1. 首先去掉那些个人理解比重大的，没有把握的内容。
2. 接着去掉一些没有在实际生产环境中被验证的内容。
3. 精简一些不太重点的，普及率相对低的内容。比如之前「模板」中对Jinja2、Mako的篇幅要多一倍，还讲到了Plim。顺便提一下，Plim在豆瓣一些应用中有使用，但是外界还没听到过用它的，本来写书也是为了推广它，受限于篇幅去掉了。
写作方式
我的写作方式是先列出大的章节，然后逐步细化，虽然我基本是从第一章到最后一章这样写下来的，但是未必是按照顺序来写，可以先编写自己最熟悉的部分，然后逐步完善。有些时候我确实是跳着写或者同时写2-3节的时候，一般是因为在在前一节卡住了，比如我在写DPark的时候，由于本地环境运行不起来而无法继续，先写其他章节；还有就是一节的内容写的太久太枯燥了，换个自己擅长的、新鲜的章节。
我使用Mou写Markdown的书稿，但是由于Mou在一些细节上做的并不好，完成一节还是会本地跑gitbook看看效果的。
和编辑做书稿review主要靠Google Drive，后来在大妈的提醒下，使用了Gitbook和Disqus插件，我和作序老师们的review基本都是在http://gitbook.io上的私有项目里完成的。
规划内容
我选择把某个软件放到书里面肯定是有原因的，比如它是业界解决对应问题的主流方案，比如它对Web开发是有意义的。首先铺垫这些原因，以及它如何解决这些痛点。接着是它的安装、配置，保证读者可以运行起来。然后通过一些实际的案例让读者知道怎么用。除此之外，还得尽量丰富内容，如和其他未在本书出现的竞品的对比分析，工作中实际经验、高级定制玩法等。我比较喜欢列表式的表达，这可能和提PR的习惯有关。大体是这样的格式：
使用XX的常见场景如下： 1. AAA。 2. BBB。 3. CCC。
或者：
这种方式有如下优点： 1. AAA。 2. BBB。 3. CCC。 4. DDD。
写作的时候，我尽力把自己换位到初学者的角度。我确实这样走过来的，只是把我学习的过程遇到的痛点，作为写作的重点。书中很偶然也会出现了在官方文档等地方能看到的内容，原因是我觉得它真的很重要，一定要着重的写出来。
有了风格，还得有一个验收的指标。我和编辑的约定是，让编辑以一个非技术从业者的角度阅读，看看读完之后，有没有了解到「它是啥」、「它能做啥」、「什么时候该用」、「它怎么玩」，「它有什么坑」等，如果编辑没有看懂，那么这节就是不合格的，再改进。
邀请作序和推荐语
首先声明，这不是编辑强制的。这是在成书后期，一个圈内好友建议的，我才意识到。问了下编辑，说人数不限。对我来说，这也是一个挑战，因为之前反正编辑又不懂技术，写出来什么就是什么。但是这些东西有没有理解正确，有没有偏离主流我也不能完全肯定。邀请别人作序和写推荐语，其实相当于项目中找人来review你的代码，我反而觉得被业界专家和其他公司的人来吐槽下更能让本书变好。
这个过程还是对我有比较深的感触的。因为大家说话有些时候不会像同事一样客气，嗯，我的心理素质还不错^.^。其次是确实学到了很多东西，而且让我对第4-5章进行的大量的重构和整理。所以我建议如果你写书，一开始就可以想好要不要邀请别人，还可以考虑让老师们分段的介入，甚至在列出大纲的时候就能给意见，这样在后期还是能省不少力的。
BTW，本书作序和推荐阵容非常强大。
写书的收益
这本书都是利用各种晚上、周末等时间完成的。我们先来计算一下写书花的时间吧。
这本书从2015年圣诞节左右开始，姑且按照2015年12月20日开始。写作完成时间为2016年5月24日。在接下来的2个多月的时间里面就是和编辑、评审老师们进行讨论和修改，其中也包含了了我对一些细节内容的调节，主要原因是事后想起来更好的表达方式，以及添加遗漏部分。8月15日基本结束写书工作。
我的日常比较规律：
1. 晚上8点半左右到家，接着陪女儿，一直到10点左右女儿入睡，如果没有其他的事情， 10点半到深夜1点半（早期是1点，后来发现进度不足以满意预期，开始晚睡）就是写书的时间。
2. 周末还是尽量找时间陪女儿，每周一般都会有一天要出去玩，除此之外要帮助老婆分担些日常事务。其实很少有机会能坐下来好好写一个小时的书，总是被各种事情打断，效率不高。周末总体上有多半天的时间能写书，大概10个小时。
好！ 我们计算下整体写书的耗时。从2015年12月20日到2016年8月15日一共240天，也就是34周多2天，每周一到周五，每天3小时，周末十个小时。其中有3个礼拜老婆带着女儿避暑去了，这也是给我放假，那段时间我的写作时间能到2倍左右。还得去掉有2周我去度假了。粗糙一点总计875小时：
In : (3 * 5 + 10) * (34 + 3 - 2)Out: 875
稿酬我选用「版税制」，书的定价是105，而我每本书可获得其中的8%，首印3000册，需要缴纳20%的税。我的收入是：
In : 105 * 3000 * 0.08 * (1 - 0.2)Out: 20160.0
最后算一下我的时薪：
In : '{0:0.2f}'.format(20160.0 / 875)Out: 23.04
如果按每月工作22天，每天8小时的标准。 额，我的月薪如下：
In : 20160.0 / 875 * 8 * 22Out: 4055.04
没有写书之前，尤其是刚工作时候，虽然没有吝啬过，但还是觉得买技术书比较奢侈。等我真的写了，才知道做知识的分享有多难，写出来说不定被喷的得多惨呢。
我还了解了一下，翻译书的译者更辛苦，因为他们得斟酌原作者每一句话，试着从原作者的角度理解，甚至于在其中发现错误并标注出来。对我来说，这显然不如自己写作那样畅快。所以大家对译者更宽容一些吧。
--- UPDATE ---
看评论画风不咋对。买书得是因为它有用啊！说出来只是让大家了解写书的收益，看评论区：
我得承认这是对的。但是在国内Python相对小众，如果确实大家觉得好，书能重印的话我的稿费确实也能挣400w... 哈哈。但目前就挣了这2W多，如果之后重印了我会来专栏更新状态的。
--- update 2016.09.16 ---
在预售时书全部发完了，连京东自营都没有抢上，所以又重印了。那么上面说的我能获得收益就要翻个倍了。感谢大家支持。
--- update 2016.10.20 ---
第三次重印，这次重印修正了这一个月收集到的本书的反馈和勘误，虽然只有2k册。
PS: 之后将不再update
--- end ---
不要纠结 Python 2 or Python 3。
正文完
知乎Live入口： 点击报名《董伟明 的 Live －－ Python 工程师的入门和进阶》
欢迎关注本人的微信公众号获取更多Python相关的内容（也可以直接搜索「Python之美」）：
