方法得當，寫書是個體力活：寫在個人書進重印2000冊之時

    前一陣子，我朋友圈裏，一位圖書公司的編輯（編輯是尊稱，按能力叫圖書中介更恰當）發文徵集Java基礎書的做者，我想，我以前好歹也出Java書，手頭有足夠的素材，並且內容也正好對口，是面向初學者的，因而就寫了份大綱發過去。

    以後半天沒有迴音，因而我主動去問，沒多久，直接回復：「你的大綱不行」，惜字如金。再請教，終於肯賜下意見，內容不適合初學者，緣由是編輯本人不熟悉Java，親身體會，看了個人大綱無法讓她理解。本人汗顏，不敢再請教，因而換了家國內某知名出版社直接聯繫，大綱略做微調後，簽下約稿合同。

    合同簽好後開始以爲慶幸，幸虧本人以前也出過書，對這方面的需求也稍有了解，也認識了很多正規出版社的計算機圖書編輯，不然這本書就懸了。但轉又一想，那些已經被該位中介指導過的朋友，若是也是第一次寫，也遇到相似狀況，會不會就此罷手呢？

    出書雖然錢很少，但畢竟能對以後找工做、拓展本身影響力乃至出掙錢的視頻教程有很大的幫助。博客園裏藏龍臥虎，我常常看到有大牛曬本身的書，我也相信有更多的朋友想出一本屬於本身的書。因此在本人圖書重印之時，結合多位資深編輯和暢銷書做者經歷，分享下高效寫書的經驗。讀完後你們估計能感覺到：「原來出書不難，大多數場景下是體力活」。

1  先根據本身的能力選點，再根據讀者羣選面

    先思考兩個問題。第一，要寫哪方面？寫本身最熟悉最擅長的方面。第二，要寫這個領域的哪些內容？定讀者羣，定目標，以後就能知道該寫哪些內容。 

    好比Java作了10年，那麼能夠寫Java方面的書。再進一步，Java有核心，web框架，項目案例，架構師等方面的寫做方向，該如何選擇？就想，這本書該給哪些人羣讀？好比給零基礎初學者讀。再思考，讀者讀好後，能有哪些收穫（這就是本書的價值）？能幫助零基礎的畢業生或入門者能幹些基本的Java項目。

    這樣內容大綱就有方向了，目前在公司裏，會基本java語法加數據庫操做加簡單的web ssm框架就能幹活，那麼就寫這些內容，並且寫做方法也明確了，因爲是面向初學者，因此能夠描述基礎知識，但絕對不能拘泥於語法，應當在書裏穿插描述些0到2年開發會遇到的坑。

    或者，某牛人作了若干年Python數據分析的工做，這領域體會很深，想出本Python數據分析的書。而後再肯定，這本書是針對有3年左右Python基礎的，那麼就能夠思考下，3年經驗的python開發離開資深python數據分析還有多少技術差距，這就是大綱裏的內容。

2  能夠參考其它同類書來準備大綱

    若是大綱裏的內容都本身列，那麼頗有可能由於閉門造車而致使市場不承認你的內容，因此在準備大綱時，能夠到京東或噹噹等網站，查下目前市面上同類暢銷書的大綱，由於這些大綱裏的內容是被出版社和市場雙重確認過。但參考絕對不是山寨，更不能原樣照搬。

    好比要寫一本Python入門書，讀者羣是零基礎的畢業生，看了若干本目前暢銷的書，發現其中都包含數據結構，語法異常處理，文件讀寫，基本庫等方面的內容，外帶介紹些基本的數據分析和圖形界面的內容，這就是制定大綱的方向，…？書的內容也應當全面包含這些知識體系。換句話說，找三本同類書，列下章節全集，你要寫的內容應該就在其中。

    但借鑑的同時要根據本身的狀況作些微調，好比一些書裏，在介紹字符串時，會全面給出相關的方法，這是別人書的特點，若是寫做目的是能幫助讀者幹項目，因此不能過多拘泥語法，在字符串方面給出些項目裏經常使用點便可。    

    這個時候，更多的就是考驗做者的功力了，做者能夠根據本身的體會，去掉些不適合當前讀者羣的內容，好比寫數據分析方面的python入門書，圖形界面這塊能夠略講，或者，大多數python高級開發在進階時，不會過多地用到list元組等數據結構裏的API，只會用到些經常使用，那麼你在準備大綱時，就能夠只講這些經常使用知識點。 

3  定好大綱後，應當用個約稿合同來確認

    先定大綱仍是先定約稿合同（或乾脆出版合同），二者。。，，都行，但在正式開始寫以前，應當用合同來確認，尤爲對於入門做者而言，不建議寫徹底書後再去找編輯，由於這樣最後的修改量會很大。

    出版社是會先在編輯會議上根據大綱等狀況肯定這本書是否能寫，若是經過後則會和做者籤合同，若是感受須要修改，這時會把大綱返回做者讓修改，修改後再評審。這個過程當中，應當是最能體現出圖書公司編輯水平。

    本人以前遇到一位很好的圖書公司編輯，他會先把大綱修改意見先過一下，可改可不改的和編輯溝通，只把大綱裏須要修改的點告訴我。但若是你們遇到的是圖書中介，那麼來回改吧，若是中介還對專業知識不瞭解，致使「傳聲筒」失真的話，那麼這個過程會更加漫長。這方面給你們的建議是：

    1 若是對本身有信心，直接找出版社編輯，聯繫方式各官網上都有。

    2 若是第一次寫，那麼能夠找圖書公司的編輯，出錢買服務。但你感受和你聯繫的中介水平通常，無法達到指導效果，或者你提交上去的大綱或稿件被反覆要求修改，且其中一些點屬於可改可不改的，那麼能夠換個圖書編輯，或者乾脆直接找出版社編輯。

    3 圖書出版社的編輯在定約稿合同時，會充分考慮做者的時間和稿酬，而有些圖書出版公司在這方面會卡得很嚴，緣由你們都知道，遇到這種對本身可能不利的合同，寧肯不籤，或者直接找出版社籤，畢竟如今圖書做者很少。

4  少堆砌理論，多用代碼說明

    在定好合同後，就能夠開始寫了。好比這章要寫Java多線程併發，該寫哪些內容？多搜些相關資料，看別人怎麼寫，而後找些適合你書的內容。

    就拿線程池舉例，能夠列些經常使用參數，也能夠經過案例說明線程池如何工做，能夠再經過案例說明項目裏線程池的用法。在多線程併發章節裏，還能夠照此寫一些信號量，鎖等知識點。在寫的時候，別大段寫理論，能夠採用 具體而言，好比1.1這個小節寫線程池，那麼1.1.1部分就寫線程池的基本概念以及經常使用參數，1.1.2部分經過案例說明如何向線程池裏增長任務，如何關閉線程池，在1.1.3裏寫一些常見的項目經驗，好比如何設置核心線程數，如何設置丟棄策略等。

    總之，讓你的每頁書裏，多少出現些代碼，截圖或表格，你的連續文字描述部分，最好別超過半頁，這樣你的書就有血有肉了。

    在執行起來，通常的作法是，先找些和當前小節相關的代碼，本身理解後，改寫一下，絕對避免有版權問題，而後在代碼下面寫上本身對這段代碼的解釋，同時經過解釋代碼來給出針對本部分（好比線程池）的描述。

5  寫的內容別「看了都懂，但對工做毫無用處」，應當儘可能加入項目中的體會

    我常常見到一些稿件，其中內容都很對，並且確實也能保證讀者看懂，好比在講Java集合時，用大量篇幅介紹了ArrayList等對象裏全部API的說明，並且針對每一個API，用表格列出了針對參數的說明。這是寫說明文檔，而不是寫書。

    寫書是要讓讀者經過看你的書，縮短進階的時間，因此從這個意義上來說，在講Java集合時，能夠講項目裏經常使用到的，這樣Vector能夠不講或略講，在講ArrayList時，能夠講它的適用場景，以及在多線程場景下的表現，這些知識點在項目裏會用到，而對於 API而言，說明下便可。

    講得再透徹些，讀者爲何不經過本身查網上資料來自學而要看你的書？第一你的書裏整理得很全面，省得讀者處處去找了，第二你的書裏確實包含了你經過若干年項目實踐總結出來的經驗，讀者至關於用錢買時間買經驗。

    因此哪怕你的書文筆通常也沒關係，畢竟這是計算機書而不是文學書，但你得儘可能用能讓人理解的文字多敘述你的體會你的理解甚至你走過的彎路，若是你本身體會不夠，那麼你就先本身多學，把你這部分學過的感覺寫到書裏，這些都是你書的賣點。

6  不下決心別寫書，論寫書時的時間安排

    通常來講，寫上手以後，2個星期能完成大概30頁的章節，這樣一個月能完成60頁，按一本書450頁計算的話，大概八個月左右能完成一本。個人寫書速度大概就這樣。

   我感覺下來，一週若是用個8小時寫書的話，徹底能達到這個進度，再具體一點，平時一天用1小時，週末用3小時。若是再抓緊些的話，週末兩天用5小時也能夠，這樣速度能更快。 

    但我就見過很多人，在寫完最多3個章節後自動放棄了，這樣不只以前的努力白費，並且會更放縱本身，之後若是再要彙集些上進心就難了。因此，寧肯不寫，要寫必定要堅持。 

7  總結，感謝出版社和編輯

    寫書自己帶來的收益確實很少，這倒不只僅是我我的的見解。但一旦有本身的書，面試時大有幫助，且當前視頻教程很是火，有了本身的書，再找相關網站製做並賣教程，難度就會下降不少。

    在找選題方面，本文提出了「按本身能力選點，按讀者羣選面」的建議，在整理大綱方面，本文提出了「多參照別人而後修改」的建議，在具體寫書過程當中，本人提出了「結合代碼說明，同時多加自身體會」的感覺，本人再照着這些步驟實施時，只是感覺身體累（由於在工做之餘或週末寫），並沒感覺腦累。

    曬下這本書在京東排行榜裏的排名，雖然不靠前，但本人資質平平，拿到這種成績也算不容易，並且今天出版社老師告訴我，這本書首印的3000冊已經快賣完，將重印2000冊，而我另外一本書，Java Web輕量級開發面試教程，最近也有重印。

   Java核心技術及面試指南，這本書是在北大出版社出版的，本身感覺下來，其中的多位老師不只能力強，在出版過程當中提了很多意見，並且在推廣方面也很是給力，之後有相似的書，也會繼續合做。