在過去的8個多月的時間里面，我完成了一本504頁的《Python Web開發實戰》。本文就是寫這本書的一些感悟和心得，如果你準備寫一本書（無論是出版社約稿還是想放在Github開源），希望本文對你能有一些幫助。如果你準備購買本書，也希望你能看到成書背后的一些故事。
寫博客 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 * 22
Out: 4055.04
沒有寫書之前，尤其是剛工作時候，雖然沒有吝嗇過，但還是覺得買技術書比較奢侈。等我真的寫了，才知道做知識的分享有多難，寫出來說不定被噴的得多慘呢。
我還了解了一下，翻譯書的譯者更辛苦，因為他們得斟酌原作者每一句話，試著從原作者的角度理解，甚至于在其中發現錯誤并標注出來。對我來說，這顯然不如自己寫作那樣暢快。所以大家對譯者更寬容一些吧。
--- UPDATE ---
看評論畫風不咋對。買書得是因為它有用啊！說出來只是讓大家了解寫書的收益，看評論區：
我得承認這是對的。但是在國內Python相對小眾，如果確實大家覺得好，書能重印的話我的稿費確實也能掙400w... 哈哈。但目前就掙了這2W多，如果之后重印了我會來專欄更新狀態的。
作者：董偉明
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
