兩年前，有幾個出版社的編輯在QQ上跟我聯系寫書的事情，好奇為什么出版社會找到我這樣一個很普通的.NET技術人員，其中一個編輯說他們分析了很多博客園博主的文章閱讀量和寫作質量，覺得我的博客還是不錯的，盡管覺得自己寫的博客不怎么樣，但想著做了這么多年技術了，準備退居二線轉行去創業，這個時候順便寫一本書作為技術生涯的總結到也不是壞事，于是和幾位編輯溝通了一下，經過選題，最終和北航出版社簽約寫書，
此時時間是2018年8月，簽了出版合同，我也辭了職，準備放松2個月再寫，國慶好好玩了一圈正式開寫，才發現寫書和寫博客根本不是一回事，而且當初簽約的時候承諾要寫25萬字，就算每天寫1000字都要寫差不多一年，堅持了沒幾天就發現連續每天寫1000字是幾乎不可能完成的任務，寫博客可以隨便寫，很容易寫1000多字的水文出來；寫書得寫得有理有據，且不能粘貼太多代碼，太多代碼的書少那絕對是一本質量低劣的技術書，另外還有一個著作權問題，編輯再三叮囑著作權問題與出版社無關，我不能抄襲別人寫的內容，要不是我之前寫了很多博客文章，完全靠自己寫書的時候鍵盤現場敲25萬字是難以想象的，于是趕緊跟出版社編輯溝通，編輯說不一定必須是25萬字，不要比這個數少太多即可，聽到這句話我心里稍稍安穩了下，于是整理了一個詳細的寫作目錄，開始一章一章的寫了，
第一章內容比較少，主要是程式員職業發展的問題，這些問題是我在CSDN論壇和各大技術QQ群里面收集到的一些討論很多的問題，主要就是作業中天天寫CRUD程式的問題，這使得作業了很多年的程式員都難以得到發展，正好我寫的是SOD框架的書，整個框架就是圍繞著如何更快更加簡單的做好CRUD的問題來的，要解決這個問題就不只是如何造一個ORM輪子或者如何使用流行的ORM框架的問題了，而是要深入到資料和編程的關系上來，要深刻的思考數和資料的本質問題，這樣我在整個第二章花費了很多筆墨來寫，最后發現這一章遠超了我的預期，它占據整本書的篇幅比例有點大，有可能使得一本技術書不是一本嚴肅的技術書，偏離整本書的重心，后來書寫完以后，果然責任編輯對此提出了較大異議，要將第二章作為“附錄”處理放到書的后面去，為此我與編輯溝通了很多次，我用霍金寫《時間簡史》的時候他的朋友建議他這本書里面要盡量少用公式來舉例，“書里面每多一個公式將損失一半讀者”，技術書的核心在于用淺顯的話語把晦澀的技術問題講明白，而我的第二章是讀者能把整本書讀明白的關鍵，
第二章寫的時間比較長，一方面是我對如何寫思考了很久，另一方面也是自己寫的不太擅長的領域，畢竟研究什么是“數”的問題是一個比較復雜的問題，需要從傳統文化領域去找答案，我認同《廣雅》里面對數的解釋：數，術也，如果說前者是數抽象的概念、符號，那么后者就是數的計算程序，且兩者互為一體，不可分割，就像太極陰陽的關系一樣，拿我們寫的程式來說，數與術的關系就好像“程式=資料結構+演算法”的關系一樣，所以說明白了什么是數，那么就更容易理解什么是資料結構，什么是演算法，最后自然就理解什么是程式，以及要怎么樣更好的來寫程式了，為了驗證我的思路，我大膽的向我兒子就讀的小學班主任申請，來給他們班免費上幾節“少兒編程”課，其中有一個環節就是讓同學們模擬原始人在沒有文字，甚至語言都還沒有完整使用的情況下，怎么樣來理解數的問題，上課的結果讓我很驚訝，小學生的形象思維更加容易理解數這個抽象的概念，甚至他們連太極、陰陽、八卦這些概念都理解了，整個課上得生動有趣，當然，這幾節課直到上完，我也沒有講任何程式語言的事情，我可不想讓他們去趕時髦教他們學Python，盡管他們學校也有資訊課，教了一點scratch，但我兒子說這玩意太幼稚了就是一個玩具，沒什么意思，所以至今我只教了我兒子一點點Scheme語言，在數學課上學以致用，就這樣，我在第二章中寫了原始人學數字的故事，以及古代部落結繩記事的知識，用Lisp來表示結繩記事的程序，來輔助理解數的概念，既然小學生都懂得起這部分內容，相信讀者朋友閱讀這一章不會有太大的障礙，第二章還介紹了河圖洛書以及八卦的演繹程序，可以作為感興趣的朋友深入研究，這樣能更好的理解關于數的“形象思維”，
第三章“資料庫應用開發”和第四章“物件關系映射（ORM）”這兩者的內容我研究的還比較深入，所以寫起來不是難事，最重要的是我之前寫的很多篇博客文章此時正好派上用場，但也不是直接復制粘貼過來就行，需要系統化整理一遍，且不能粘貼很多代碼影響閱讀體驗，所以書中很多帖代碼的地方都能看到“此處代碼略，，，"的情況，有SOD框架的老用戶拿到后來我這本印刷出來的新書說這兩章看起來有”很熟悉、很親切的感覺“，這說明SOD框架的”簡單易用“特點非常受老用戶肯定，第五章“資料表單開發”在現在Web應用流行的情況下，以及各種Web前端技術框架的大量使用下，這一章介紹的WinForm和Web Froms資料表單開發技術顯得有點“冷門”，但只要是用過的朋友都知道SOD框架對此的支持是很完善的，能夠一行代碼完成表單表單資料的增刪改查，且支持MVVM資料系結，為了體現SOD框架非常易于開發資料表單這個功能特點，所以盡管這一章內容不太多，但書中給的例子是我完全重新開始一步步手把手寫的教程，其中的方法拿來即用，希望大家對Web Forms/WinFrom能夠有新的認識，
第六章 “分布式系統架構與資料開發”算是我10多年架構作業經驗的總結了，為了彰顯書的主題，這一章里面介紹都是架構設計開發中跟資料密切相關的內容，包括分層架構的資料訪問和處理，DDD/DCI架構、洋蔥架構的一些概念，以及綜合各種架構特點的“分布式混合架構”實戰的內容，甚至探討了如何有效的進行業務分析的話題，這一章還包括企業應用中常見的資料分布式、分表分庫、讀寫分離、分布式事務的知識，介紹如何用SOD框架來更簡單的實作這些功能，第七章 “企業級解決方案應用示例”算是第六章的姊妹篇，他們都是基于我在以前作業過的幾個公司負責的一些重點專案使用的技術架構方案的實踐介紹，其中“應用層事務資料復制“方案PK過了原公司專案后期空降的海歸總監基于Java+MySQL的技術方案，實踐證明這個方案對比MySQL基于binlog實作的資料復制在開發難易度以及性能安全性方面更有優勢，
最后一章做了一些框架的資源介紹，以及一份感謝名單，還有一份放到“后記”的寫作感言，等到寫完這一章，才發現自己已經寫了整整一年時間，時間已經是2019年9月，寫完發現居然已經超過了30萬字（不包括英文代碼和空格這些），差點不敢相信自己這樣堅持下來了，用“掉了一層皮”來形容不過分，甚至像另外一個寫書的朋友說的，寫完一本書都“寫禿頂”了（幸好我頭發天生很多），
書寫完了但寫書的事情并沒有完，上面說的只是寫完了”草稿“，還需要自己校對以及撰寫書的前言、請朋友作序、寫目錄介紹等，其中有幸請到了.NET領域的標桿隊長張善友同學和.NET Linux Web服務器Jexus作者”宇內流云“前輩做序，他們寫完還差一位Java領域的專家支持，因為寫書之前和出版社說好了”純.NET的書不出“，市場上純.NET的書比較少，出版社出于市場考慮不得不蹭熱度出流行的書，比如Python的書如雨后春筍，以至于我這本書的上架建議寫的是”大資料“類，雖然我覺得這個上架建議不太合適，但也沒有更貼切的上架分類，最后終于請到了一個Java技術專家幫忙寫了一篇序言，沒想到他對我的書評價還不錯，這讓我有點意外，（參考他寫的【序三】），
一邊約朋友幫忙寫推薦，一邊和出版社進行審稿校對，出版社要經過“三審三校”，流程復雜，與責任編輯的溝通程序“比較痛苦”，糾錯別字都是小事，的問題是編輯覺得你有些地方寫的不好，要進行刪改，有些地方甚至要進行大段的刪改，碰到這個事情你的心臟得要好才行，另外一個麻煩事情是要給出書中參考的圖片和文字的完整來源，如果一開始沒有注意這個問題到寫書完了才來做這個事情是相當無語的，我在網上零星摘抄的文章部分內容大都找不到原來的網址了，編輯一再強調有著作權問題“你自己負責”，事已至此，我自己負責就負責吧，身正不怕影子歪，我確實沒有大段的抄襲過別人的文章，也沒有使用過有著作權的圖片，稿件校審期間又遇上了兩次新冠疫情，最后終于通過最后的校審了，時間已經到了2020年6月份才送印刷廠，等7月我拿到印出來的樣書，距離最初完稿差不多又過了一年，拿到新書那一刻，已經完全沒有了興奮和喜悅的感覺，只是覺得這件事情終于告一段落了，當然還有后期結算稿費的事情，這里不表，這樣，從簽合同開始到最后上市，這本書差不多寫了整整兩年時間，
書寫完書能不能賣出去成了新的問題，為此我建立了一個網站來宣傳，給粉絲做售前售后服務，期間又是另一種心酸，這里先不表，感興趣的朋友可以移步我的在線銷售網站試讀，以及讀者的閱讀和圖書評價，
最后就是我昨天去北京最大的新華書店--西單圖書大廈，在四樓計算機圖書區域，偶然看到我的書放到了“大資料”的書架上，有點“悲喜交加”的感覺，“悲”的是我辛苦兩年寫的書在電商平臺銷量并不好（當然跟我的銷售策略失誤有關，也跟出版社的宣傳推廣有關），這兩年寫書對我創業和找作業帶來了比較大的影響，把最重要的事情給耽誤了； “喜”的是竟然能在線下書店特別是西單圖書大廈看到“它”能在這里有一席之地，也心滿意足了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/233428.html
標籤：其他
上一篇：初入職場，菜鳥程式員如何才能成為業界大牛，給你提供思路方法。
下一篇：HO引擎近況20201212