前一陣子，我朋友圈里，一位圖書公司的編輯（編輯是尊稱，按能力叫圖書中介更恰當）發文征集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核心技術及面試指南，這本書是在北大出版社出版的，自己感受下來，其中的多位老師不僅能力強，在出版過程中提了不少意見，而且在推廣方面也非常給力，以后有類似的書，也會繼續合作。
