心路歷程：爬蟲實戰——從數據到產品

京東連接：item.jd.com/12575102.ht…

通過近一年的辛苦創做、編輯、等待，本書終於出版了。這種感受有點像是十月懷胎，但沒有生育時候的痛苦，只有最後獲得的欣喜。如今回憶起去年接到著書的邀請，而後到糾結，再到剛開始痛苦的寫做，以及最後成稿後的釋然，一切都以爲是一場人生的經歷。我卻是認爲著書的目的不是爲了賺錢，寫一本書給本身，總結本身的過往，將經驗傳播給他人，就能夠了。

故事——還得從2017年提及

2017年1月左右，摩拜單車終於進入到成都。不像重慶那樣的上山下坡，成都平原地勢較平，成都本來就有很是多騎自行車的人，街頭巷尾都有自行車的蹤跡。做爲短途的必要交通工具，摩拜單車的進入算是給出行帶來了很是大的方便。

有一天在查看摩拜單車的APP的時候，突發奇想是否能夠將這些車的位置數據拿到，而後嘗試分析一下運營情況，看當作都到底有多少車。打開電腦，輕車熟路的進行API分析，搞明白了API的接口，而後就寫了一個簡單的爬蟲，獲取了一個月左右的數據並進行了分析。而後在簡書上發了幾篇文章，並將源代碼放在了github.com/derekhe/mob…這個repo中。

出乎意料的是，這些分析竟然獲得了很是大的流量，兩三天時間就到了1萬多的閱讀量，甚至這個數據分析還「成功」的引發了對方的注意：被問到你怎麼獲得數據？

2018年

2018年，順着這個思路，後來我又繼續分析並爬取了共享汽車、自由職業者網站，並繼續堅持將2016年6月開始作的機票的數據爬蟲作得更快更穩定。

2017年底，愛飛狗旅行小程序上線，將我收集到的機票的數據公開，並集成了一個預測系統。知曉小程序對此特地寫了一篇文章進行報道。隨後，在2018年下半年ThougtWorks對外的YottaBytes分享中，我將愛飛狗的整個產品的規劃、開發以及背後的技術實踐都分享出來，並寫成文章。

著書？

2018年3月底，電子工業出版社的安娜編輯聯繫我，看我能不能約一本書稿。當時我還沒放在心上，想一想寫個書算是一個大工程吧，費時費力的，當時就想一想要不仍是算了？後來和編輯的更多溝通中發現，爬蟲方面的書最近還比較熱，也能熱一段時間，我作的這些工做也剛好和爬蟲很是有關。

我隨後看了一些目前的爬蟲相關的書籍， 發現不少爬蟲的書籍都寫得很初級，講講Python的語法、講講幾個庫的用法，弄兩個例子就完了，甚至有些書竟然用了76頁講各類東西的安裝！！初級的爬蟲每每很簡單，爬幾個網站便可，但更復雜的如何去拿到app的數據，如何破解一些sign的思路，卻全然沒有。或許是太複雜了吧。即使有些數據拿到手了，怎麼分析，怎麼可視化，也不多有講解。

若是我要寫的話，我必定不會寫這樣的書，我不會寫初級的書。我要寫的話，必定是從一個想法開始，到如何實現這個想法，到如何解決各類困難。案例的話，必定是end to end的，將數據達到實用的階段。

還好以前作過的各類數據分析案例，都是有必定的業務背景的，有一些數據提供給了一些愛好者進行了更深刻的分析，有一些數據甚至幫助一些公司進行一些新業務的拓展嘗試。我和編輯溝通了這些想法，那就開始動手吧！（其實心裏是有點糾結的，由於想到要寫很長的時間，很是的難受）

那就開始吧

這是最原始的選題單，能夠看到其實當時想寫的例子其實比如今書中呈現的更多。但後來因爲目標網站改動太大，以及有些網站的例子不太合適，因此進行了刪減。

最後，只有半年的時間啊……

萬事開頭難，先寫個提綱吧：

開始

工欲善其事必先利其器，2009年寫過研究生的論文，卻是對Word玩的很溜。但現在都2018年了喲，好歹用點Markdown對吧！

好吧，就用Markdown。可是用Markdown的話，我須要把每一個章節分開麼？後來嘗試了一下發現，單一Markdown文件就很是利於管理，不用有潔癖同樣把東西拆來拆去：

• 方便預覽整書狀況
• 方便章節之間相互引用
• 避免調整章節時候的麻煩事

而後，在Visual Studio中安裝了Markdown Preview Enhanced插件，這個工具很好：

• 自動預覽
• 自動生成目錄
• 自動內嵌圖片、內嵌代碼
• 可以導出成多種格式（Word格式、PDF格式等）

最後，整個項目固然會用git進行管理，這是最基本的啦。

其中我以爲須要拿出來說的是，Markdown中能夠直接引用代碼。這意味着我一邊著書一邊寫的代碼，能夠無縫的集成到文章中，這樣我更改了代碼之後，書中的代碼也更新了，避免了不一樣步的問題。

一年

如今回顧一下整個過程。

我這我的是喜歡一氣呵成作完一件事情。爲了保證及時交付，天天都分配了至少兩個小時的時間，再加上以前已經有一些素材的積累，因此整個書的書寫都相對比較快。基本上在4個月時間內集中寫完了書籍。初稿完成後，個人事情就比較少了，主要是一些校對的工做。

• 4月底：創建Repo
• 5月初：書寫第一章
• 6月初：完成單車部分書寫
• 6月底：完成共享汽車部分書寫
• 7月底：完成Freelancer部分書寫
• 8月初：增長愛飛狗產品
• 9月底：完成全部書寫，並轉換成docx供編輯修改
• 10月初——12月底 一排
• 12月底到1月初： 二排，拿到書號
• 2月底：終審
• 3月中：封面、查重、訂價
• 3月底：樣書到

經驗

• 持續和編輯聯繫，寫完一章就給編輯大體看看獲得反饋 這一點避免了不少走彎路。第一次著書，對著書須要作的事情瞭解的比較少，加之平時在敏捷項目中都強調快速反饋，在著書過程當中也是，可以及時避免一些坑。
• 一氣呵成，堅持天天花些時間寫，避免拖拉
• 長期寫博客，積累素材

坑

在著書的過程當中也有一些不可避免的「坑」。一來是著書不像是寫博客那麼隨意，對於語言以及內容的提供都要有一個監管在裏面。運氣很差的是初稿交了之後，編輯告訴我2018年國家對地圖相關的圖片管理很嚴。我瞭解到相關的書籍都必需要進行審覈，雖說是免費，可是爲了不審覈的時間消耗和一些潛在的風險，咱們對書中的一些地圖相關的圖片、內容進行了一些修改和刪減。

爬蟲這種技術有必定的法律風險，再三考慮之下對書中也有提到一些特定APP名字的地方，咱們將名字進行了打碼，並強調了這些思路以及代碼都僅供參考。

初稿的反饋說書寫的很直白，全是乾貨，審覈後說是要語言柔和一些。因爲這個書的架構和其餘相似書籍先將一大堆基礎知識不同，出版社的領導提議說將書的結構進行調整，變成介紹工具在前，案例在後。但這就是我想盡力避免的，不想讓讀者的錢花到了本來網上能夠很快查到的地方，因此拒絕了。

因爲互聯網時代變化很快，網站和APP都在改版，因此爬蟲相關的代碼，目前有些已經沒法使用了。這是預料之中的事情，但書中所傳遞的方法，是通用的。

總結

無論如何，第一本書也算是出來了，放在書架上也是對個人極大地鼓舞。著書不容易，一旦開始就要一氣呵成。平時的積累很是重要，因此多多寫博客吧。

PS：掘金很奇怪啊，xieshu、chushu（自行腦補）都是關鍵字，不給發表。只能改個詞語了。