兩年前，有幾個出版社的編輯在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月我拿到印出來的樣書，距離最初完稿差不多又過了一年。拿到新書那一刻，已經完全沒有了興奮和喜悅的感覺，只是覺得這件事情終於告一段落了，當然還有後期結算稿費的事情，這裡不表。這樣，從籤合同開始到最後上市，這本書差不多寫了整整兩年時間。

    書寫完書能不能賣出去成了新的問題，為此我建立了一個網站來宣傳，給粉絲做售前售後服務，期間又是另一種心酸，這裡先不表，感興趣的朋友可以移步我的線上銷售網站試讀，以及讀者的閱讀和圖書評價。

    最後就是我昨天去北京最大的新華書店--西單圖書大廈，在四樓計算機圖書區域，偶然看到我的書放到了“大資料”的書架上，有點“悲喜交加”的感覺，“悲”的是我辛苦兩年寫的書在電商平臺銷量並不好（當然跟我的銷售策略失誤有關，也跟出版社的宣傳推廣有關），這兩年寫書對我創業和找工作帶來了比較大的影響，把最重要的事情給耽誤了； “喜”的是竟然能線上下書店特別是西單圖書大廈看到“它”能在這裡有一席之地，也心滿意足了。