如何寫好技術文章/書籍：四個指導原則

標籤： 公衆號文章

---

不知不覺專職寫技術文章/書籍的時間已經有兩年了，剛開始是摸着石頭過河，什麼東西都是嘗試着來，今天再回頭看我最初寫的一些東西仍是蠻幼稚的，但願再過兩年看我今天寫的這些東西也能產生這種感受吧（那才能說明我進步了嘻嘻）。

當咱們從事一門工做時，首先要界定清楚咱們要達到的目的是什麼。對於寫技術書籍/文章的我來講，目的很簡單，就是：讓同窗們更快、更溫馨的掌握我想讓他們掌握的那些知識。達到這個目的比較困難，不過在不斷探索中逐漸造成了我本身的一套寫做方法論，今天這篇文章就着重於我本身提出的寫技術文章的四個指導原則，主要是給下邊兩類同窗看：

• 對於剛剛開始寫做的同窗們，但願你們能夠少走些彎路。

• 對於學不懂某一門專業知識的同窗們，雖然我不能讓你們當即把專業知識學會，可是至少可讓你們明白本身爲何學不會。

  小貼士： 個人一個觀點：對於大部分工程技術問題來講，理解並掌握它們並不須要很高的智商，可是須要解釋這些問題的人下一些功夫，從初學者的角度出發來解釋問題。也就是說：學不會東西不怨你們，是咱們的文檔沒寫清楚～

好的，廢話少說，所謂的寫技術文章的四個幾本原則就是指：

• 簡單
• 簡潔
• 有趣
• 系統

咱們下邊分別來看一下。

簡單

計算機是一個很是精密的機器，咱們能夠用歎爲觀止來形容，簡直比藝術品還藝術品。不過即便是通過成千上萬科學家精心研究的這個藝術品，底層也只不過是由一堆晶體管組成的，咱們做爲程序員平時使用C、Java這些高級語言寫出的程序實質上是在操縱這些晶體管。比方說咱們用C語言敲了一行printf的代碼，而後把它編譯運行，最後在屏幕上把它顯示出來，這樣的一個簡單的操做，實際上是通過層層調用獲得的：

• 咱們的應用程序（這裏是一個C語言的程序）會調用操做系統提供的往屏幕上輸出一行字的接口，稱之爲系統調用，不一樣廠商能夠生產不一樣的操做系統，比方說Unix、Linux、Windows之類的。

• 操做系統接收到須要往屏幕上輸出一行字兒的指令和內容以後，會調用相關硬件的機器指令，這些機器指令其實就是010101...這樣的二進制代碼。不一樣的廠商生產的不一樣機器有不一樣的機器指令體系，比方說x86、MIPS、PowerPC等等等。

• 這些010101...二進制代碼它們自己沒有啥意義，針對同一個指令體系來講，不一樣的廠商能夠針對一樣的機器指令畫出不一樣的電路圖，比方說對於x86機器指令的體系，Intel公司和AMD公司能夠真對同一個機器指令開發出不一樣的電路圖，這個電路圖就是所謂的微體系結構。

• 電路圖其實就是個圖，它是由各個具體的邏輯組件組成的，比方說作加法須要加法器，作乘法須要乘法器，存儲數據須要觸發器吧啦吧啦的。

• 而這些邏輯組件本質上是數字電路，由與、或、非以及其餘的一些基本邏輯門構成的。邏輯門仍是一個抽象的概念，它假設電路里只有0和1兩種狀態，可是實際的電路中只能靠電平（或者說電壓）來表明電路的狀態，而電平的變化是一個連續變化的過程，不是單純的從0點平直接跳到1電平，因此咱們把在某個區間內的電平認爲是0，某個區間內的電平認爲是1。

• 模擬電路中的電平信號是連續的，它是靠底層的一些硬件來導電的，比方說繼電器、真空管、晶體管啥的。

• 繼電器、真空管、晶體管這些器件是怎麼導電的呢？咱們只能認爲這是大天然的魔力，或者說大天然的一種規則。

從這個過程能夠看出來，這樣子的抽象把一個極其複雜的問題分配到了不一樣層級去處理，就像把軍隊分紅軍、師、旅、團、營、連、排、小工兵同樣，最高級別的指揮官會下達一個較爲抽象的命令，比方說把某個地方給攻佔掉，以後這個命令層層落實到最基層，每一層都有本身的任務，可是最具體的任務仍是要給小兵去完成。

說了這麼多，咱們只是想說一個極其複雜的系統背後確定是有其抽象層級的，做爲解釋者的咱們須要把這樣的抽象層級給解構出來，直到解構到足夠簡單讓用戶理解，而後再把它們串聯起來造成一個大的系統。爲了作到簡單，咱們給出一些能夠落地的建議：

• 清晰的結構劃分。

  這個過程相似於思惟導圖，咱們首先搞清楚本身要講清楚的主題是什麼，而後這個主題是由哪幾個部分組成的，每一個部分又能繼續化爲更小的哪些部分。化成的這些部分的相互依賴關係是如何，千萬要記住一條硬性規定：不要用一個沒有解釋過的概念去解釋另一個新概念，這種狀況是致使用戶學不懂的首要元兇。

• 魔鬼藏在細節裏，對一個概念的充分解釋

  不少同窗覺得寫的字越少，可能意味着越精華，這純粹是胡扯。個人經驗是咱們給出的細節越多，讀者更容易理解，讀者在越多過程當中會產生不少疑惑，細節列出的越多，留給讀者產生疑惑的狀況就越少，這樣他們的思路就更不容易被打斷。

• 把某些不適合展開討論的概念看成黑盒對待，可是要顯式的對讀者聲明

  咱們的文章/書籍的篇幅有限，不可能把每一個概念都講述的十分清楚。這時候咱們的首要思路是想辦法繞過這個概念，在使出渾身解數都繞不過期，須要顯式地跟讀者說明這個概念咱們暫時不講，只須要知道它有一個什麼樣的屬性就好。

  小貼士： 就個人寫做經驗來講，那些當前還不着急介紹的概念十有八九都能繞過。

簡潔

簡潔直白一點兒的翻譯就是廢話不要太多。

• 咱們在寫做以前必定要明確本身介紹的主題是什麼，而後與這個主題全部無關的東西均可以算做冗餘部分，能夠用一句或者兩句話介紹帶過。由於對於無用概念的過多介紹會讓讀者下降讀者注意力，分散注意力的後果就是他們可能分不清那些是重點，哪些是沒用的。

• 避免概念過多出如今一個地方。

  若是你發現本身在某個不長的篇幅裏連續引入了大量的概念，並且看上去密密麻麻的介紹性文字，中間也沒啥段子的話，那你就要當心了，這樣的篇幅容易引發讀者不適，不少人會下意識的先掃一眼，發現裏邊有好多本身不認識的詞兒，內心立馬就有了抵觸，這種抵觸情緒會影響到他的閱讀體驗，從而更難真正理解你所描述的內容。因此若是你須要在某處介紹大量概念的話，這時你就須要考慮如何拆分這些概念，你能夠把它們拆成不一樣的主題，或者在同一主題裏拆分到不一樣的地方去描述。

• 圖表讓文章立馬變得簡潔

  語言在圖表面前是十分蒼白的，真滴～

有趣

首先說一下，有趣和簡潔在不少地方都比較衝突，若是你想讓文章更有趣，那就得適度犧牲簡潔，把握好度比較重要，這個度就像廚師的火候，不可說～

• 能用咱土語描述的就千萬別扯過多的專業術語，專業術語用多了，就成了文言文，讓人看多了就忘了是個啥意思。有的時候爲了表述某個觀點你以爲漢語不夠使了，你扯點英格蕾絲也是能夠的嘛。

• 段子該用就用，甚至能夠是咱們刻意設計的，笑點掌握在本身手中那是種高級境界，我目前還差着遠呢～

• 注意趣味性不能喧賓奪主，淪爲兒童讀物。

系統

系統能夠表述爲一種知識的閉環，寫書的時候尤爲要注意，寫單篇文章的時候也要稍微注意一下。

就是說咱們把要講述的那些主題劃分紅多個模塊後，將每一塊的依賴關係劃分出後，先講那些簡單的，再講那些複雜的，最後所有都聯繫到一塊就造成了咱們要討論的主題，針對每一塊，咱們都要考慮清楚：

• 咱們在講什麼東西？
• 爲何會有這個東西？
• 這個東西有什麼用？

一個概念的產生不是憑空想像出來的，它是有它存在的環境的，咱們把它們誕生的情景說清楚，而後把它們和其餘模塊的依賴說清楚，就能夠造成一個渾然天成的體系，用戶們也就能夠得到一個慢慢的學習成就感。

關於正確性

咱們怎麼沒有嘮叨內容的正確性呢？哈哈，這玩意兒還用強調麼，多找幾本參考書，多對照着源碼看一下。雖然咱們是人就可能犯錯，可是但願能夠儘可能讓錯誤少一些吧～

結語

但願咱們的技術文章/書籍愈來愈好，曾經幫助過我宣傳《MySQL是怎樣運行的：從根兒上理解MySQL》的公衆號「架構師之路」的博主沈劍老師對我說：「我是技術人，不是商人」，與各位共勉，儘可能改變一下國內技術書籍晦澀難懂的現狀，一塊兒加油⛽️

題外話

寫文章挺累的，有時候你以爲閱讀挺流暢的，那實際上是背後無數次修改的結果。若是你以爲不錯請幫忙轉發一下，萬分感謝～ 這裏是個人公衆號「咱們都是小青蛙」，裏邊有更多技術乾貨，時不時扯一下犢子，歡迎關注：