開場白
輸出倒逼輸入
作為一個技術人，我們往往都沉浸於技術的海洋中學習。 在學習技術的過程中，我們不斷的在輸入知識，同時我們也需要關注輸出。 輸出是也一種學習的過程，無論是寫部落格、寫文章、寫書，還是做分享、做演講，都是一種輸出的過程。有時輸出是你堅持學習的動力，有時是你鞏固和總結學習的過程，有時是你向別人傳遞知識的方式。"費曼學習法" 其實就是輸出的一種形式，它的核心思想是：如果你想要學習一件事，那麼你就需要把這件事教給別人。
說到輸出，其中一個非常重要的技能就是寫作，寫作是一種思考的過程，也是一種溝通的方式。 在寫作的過程中，我們需要考慮的問題有很多，比如如何取標題、封面配圖、如何搭建文章結構等等。
我也是一個技術博主，在寫部落格的 6 年時間裡面， 我也不斷地在積累和思考，如何去更好的寫作。今天，就圍繞著如何搭建文章結構，如何進行取標題、封面配圖等等，我將一個開發的視角分享一些我自己的經驗和思考，希望能夠幫助到你。
當然，下面的分享針對與文章、部落格型別，對於書籍或是論文的寫作有著更加專業的要求，這裡就不做過多的討論。 由於本人對於後端的知識更加熟悉一些，所以文章中具體的案例會偏向底層一些，但不用過多擔心，你只需理解抽象的概念，具體的案例我相信你也就能理解了。
為什麼要寫好？
我相信，你既然看到了這裡，一定已經解決了第一個問題，為什麼要寫。我覺得無論寫作的內容是什麼，只要你踏出第一步，那麼我就覺得你比許多人要成功了，因為你已經開始了，而不是一直在想要開始。那麼我主要來討論為什麼要寫好。
雖然說技術文章，不像寫散文、記敘文，需要華麗的詞藻或者是一些倒序插敘的寫作手法，所以我們常常看到的就是非平鋪直敘。但並非說它的行文就可以沒有章法。
有人可能會說：技術文章的重點不應該是內容嗎？
沒錯，當然！技術文章的內容往往是吸引人的關鍵，作為一篇技術文章，別人想要讀的前提就是他對你說的這個知識不瞭解，或者是對於你說的這個問題沒有答案。所以我一開始就覺得，只要我的文章中有你想要的答案，就可以了。
但是當我拜讀了許多的文章之後才發現，原來不是這樣的。厲害技術文章不僅僅是內容，邏輯框架非常的重要。邏輯框架清晰的文章能讓讀者迅速理清思路獲得知識，同時還有以下幾個好處：
好處 1：方便回顧
技術寫作的其中一個目的，應該是自己對於一個技術或者知識的當下理解，它很多時候承載了你的筆記這樣一個功能。所以，當幾個月或者是幾年後，當你想要查詢當時的解決問題的思路時，一個好的邏輯框架能非常快速的幫回憶起你當時的想法並找到答案。
好處 2：建立正向迴圈
寫作寫好的另一個巨大好處，就是能夠獲得讀者的認可，當你的文章容易被別人閱讀的時候，別人才會給你更多的意見和建議，這樣的建議往往能促使你更好的寫作，從而形成一個正向迴圈。寫作 -> 建議 -> 寫的更好。
好處 3：快速創作
有時候，當你想要寫作時，往往只是一個念頭或者想法，想要成文，還需要花費很多的時間。你需要圍繞你想要寫的主題，來構思整個文章的前因後果。而一個好的邏輯框架能夠幫助你快速的把想法轉化為文字，從而快速的創作。 有了一個好的骨架之後，你只需要不斷填充，一篇邏輯清晰的文章就能迅速成型。
我經常會使用的一種創作思路就是，積累+總結。比如，當我對於一個新的認識有自己的看法時，我馬上將它在筆記上記錄下來，然後再一週內不斷地積累相關聯的知識、背景、資料等等，最後再週末的時候將它們整合到一起，從而形成一篇文章。因為很多時候當前你對某個知識的理解是片面的，不完整的，在尋找相關資料的過程中能讓你對它有更加深刻的理解。
而在最後整合和總結的過程中，就需要用到我們下面要講的邏輯框架了。
問題提示
提出問題不僅僅是為了吸引讀者
第一個框架，也是我最常用的一個行文思路，就是提出問題。 許多的技術文章並非寫的不好，而是沒有一個好的邏輯框架，導致讀者在閱讀的過程中很難理解作者的思路，從而導致文章的閱讀完成率很低。
而針對與技術文章，特別是一些困難的技術分析文章，往往就會有一個問題，就是我看著看著，就沒有辦法理解這個知識了，或者說我看完就看完了，但好像又沒學到什麼東西。
那麼，或許使用問題提示法就能幫助你解決這個問題。
框架
- 提出問題
- 解決/回答 問題過程
- 總結和提升
你肯定會說，這麼簡單？這不就和我現在寫的事故分析報告差不多嗎？先列舉問題，然後分析問題產生的原因，如何解決防止下次出現。
沒錯，很多時候簡單的東西往往容易被人忽略使用。最關鍵的是它能用在何處？
舉例：原始碼分析
如果，你對技術比較喜歡，對於一些開源的技術實現，學習原始碼往往能讓你快速理解這個專案，並且能學到很多編碼設計上的技巧。所以原始碼分析類的文章也挺常見，但是許多文章有一個一致的問題，他們的文章大多數就是將程式碼的跳轉路線告訴你了：
入口在哪？從那個方法進來，到那個方法去，這個方法是做什麼的.... 等等，當你看完之後，你就會發現，你剩下的幾乎沒有，回過頭你發現你等於沒看。或者是當整個專案非常複雜的時候，往往方法和類的擴充套件很多，導致你看到最後，你都不知道在哪裡了。還不如自己執行程式碼，跟著斷點除錯來的方便。
那麼，文章的問題出在哪裡呢？我們要如何使用這個框架改進呢？沒錯，合理的設計問題，也是在考驗你對於整個技術實現的理解。比如你可以這樣設計問題：
在閱讀原始碼之前，你可以思考一下，如果是你，你將會如何實現它？
再比如：
為什麼這個技術能處理的如此迅速？原因是什麼？
然後，當你在敘述整個原始碼實現的過程的時候，你就可以時時刻刻圍繞這個重點去闡述：
比如：這裡資料結構的設計對於整個實現是有很大幫助的，如果我設計，可能無法想到用這個結構，以後可以用到
比如：你可以寫，不要忘記我們的問題，關鍵在於如何迅速處理，沒錯，這裡就是問題的關鍵，由於這裡用了....技術...能幫助它更快的處理...
最後，不要忘記，在總結的時候再次回答這個問題，讓讀者一定產生：哦，原來是這樣的感覺。
優勢
那麼使用這個框架所構建的文章就很明顯，讓你原本平鋪直敘的文章有了一個主心骨，原本無依無靠的零散的知識點，都是為了這個主心骨服務的。
這樣，讀者在閱讀的過程中就會時時刻刻圍繞著這個問題去思考。即使當我們有很多很複雜的專案時，我們的問題也有有多個，只要圍繞著問題去寫，讀者就能迅速將思維更上，從而不亂。
並且，就像前面說的，當你很長一段時間回過頭來複習的時候，你不需要看整個文章，你只需要口述回答你最前面提出的問題，你就能迅速回憶起來整個知識點。
擴充套件
當然這樣的框架並非只能用在原始碼分析的文章中，還有類似的還有分析框架、分析中間實現等等，都可以嘗試用這樣的框架去構建，會讓文章更加清晰。
開門見山
即使直接上結論，讀者也不會逃跑
在學校的時候，老師總是會告訴我們，寫作的時候要有一個開門見山的思路，也就是說，你的文章要有一個明確的主題，而不是一上來就開始寫，然後到最後才說，這篇文章是關於什麼的。
而在當下，厲害技術太多了，很多人都喊著學不動了，躺平了。並且在短影片，這樣短頻快的節奏之下，已經很少有人能耐心仔細的看完你的文章了。
那麼，反應到技術文章，大多數人追求的是什麼？答案，他們只需要一個結論，其他的全部略過，知道結論彷彿就知道了全部，如果在文章中，無法迅速找到結論，那麼他們會迅速切換下一個搜尋結果。
這也是為什麼很多時候在搜尋英文報錯的時候，很多人看著英文文章無法找到答案，無法解決問題，其實答案就在其中。那麼此時，我們就需要用到這個框架。
框架
- 直接上結論
- 理論論證
- 總結原因
直接上結論，會不會導致讀者就看個結論然後就走了呢？讓我們慢慢往下說
舉例：技術選型
很多時候，在實現一個功能或者一個需求的時候，有很多的方案供我們選擇。常見的就是兩個開源專案的是實現，或者兩種技術方案的對比。當我們在做選擇的時候，往往就會去詳細調研兩種不同技術的優勢和劣勢。又或者是隻有一種技術，用與不用也是一種選擇。用是因為什麼，不用是有什麼原因。
那麼對於這樣的文章，我們就可以嘗試運用這樣的框架去寫。
首先，我們可以上來就直接說明，我認為：應該選擇使用這個技術，並且我已經將之實踐了。
然後，你就開始從各個維度進行論證，為什麼：
- 比如從使用角度
- 從程式碼的實現角度
- 從維護成本出發
- ...
在論證中，最能給到使用者肯定的就是資料，如果你能拿出你的實際測試資料來說話，會更加有說服力。
最終，你是在什麼樣的場景下，做出了什麼樣的選擇。並且可以總結很多實踐過程中，出現的問題。
優勢
這樣的寫作框架與說明文的寫作有著類似的道理，優勢在於：
- 快速讓讀者知道你的觀點
- 清晰的論證讓你有足夠的靠山
- 最終讓讀者清晰的明白你選擇的場景，是否他有參考的意義
原因
很多人就會說，別人肯定會看了開頭就走了。但其實實際並非如此：很多人其實在看文章的時候一開始都是大致掃一眼，去搜尋他們想要的資訊，而當他們無法找到資訊的時候就會走。
而看了這個開頭的使用者往往反饋就兩個：
- 同意你的觀點
- 不同意你的觀點
對於同意你觀點的人，無非就兩種，一種是已經對這個知識非常熟悉了，這樣的人其實並不是你的受眾，你這樣做非常可以節約別人的時間。還有一種就是他同意你的觀點，但是，只是他的一個個人想法，並沒有人支援，那麼他會繼續看下去，找到你這樣說的理由。
同樣的不同意你的人也是類似的道理。抓住了使用者的第一眼，很多時候就能綁住使用者。
擴充套件
當然 技術分析、專案分析、優勢分析，等等文章都可以使用這樣的方式去寫作。
鋪墊基礎
讓你的文章滿足更多受眾
對於特別難得知識點或者問題，我們往往需要一些前置的知識來做鋪墊，鋪墊的好與壞直接就決定了文章的閱讀體驗。
我也經常在看一些底層技術的文章，對於同一個內容，有的文章閱讀很順，從頭到尾，讀完就學會了；而有點文章就很難，看完之後你還需要去找別的文章，最終拼湊出你想要的結果。
於是乎，有時，對於特別困難的技術說明型別的文章，我就會嘗試採用這樣的寫作框架來幫助我。
框架
- 前置邏輯/知識儲備
- 推導中間狀態
- 最終得出結論
- 引用各類觀點
舉例：難點技術
這裡的案例我實在是找不到合適所有讀者的說辭，只能以具體的一個案例進行說明，我會盡可能用大家都懂的語言來解釋。
“IO 多路複用 ”是一個非常複雜的技術難點，如果直接上來就告訴讀者，它是怎麼做的，如何實現的，然後貼一貼程式碼，這樣很難讓人明白。或者說不太友好
那麼，如何去做鋪墊呢？你可以從以下幾個方面著手：
- 使用者空間和核心空間
- 程式切換與阻塞
- 檔案描述符是什麼
- 標準 I/O 怎樣的
然後，你就可以順理成章的推匯出 IO 多路複用的實現原理，以及和標準 IO 相比它的優勢在哪？為什麼要用它。
當然，在得出結論之後，我的建議，這樣型別的文章，你想要提升，一定要給一些文章站穩腳跟的連結，並且對於一些知識點，你可以引用你之前寫過的部落格連結，這樣不僅能縮短使用者的尋找時間，還能幫助你其他部落格的引流，也算是一個小技巧吧。
原因
對於困難的知識，很多人其實難以理解的原因往往是由於前因後果沒有搞清楚，前置的基礎知識沒有掌握，你直接告訴它最終的結論，往往會很難讓人明白。
優勢
這個框架對於讀者來說非常的友好，相當於新手和一知半解都能真正在你的文章中 “順理成章” 。
而這個框架我特別喜歡的還有一個原因是：在寫作的過程中，它幫助我去回憶起之前很多的知識點，幫助我在不經意間構建了整個知識網路，讓我明白這個知識點在我的整個網路中處於哪一個節點，與之相鄰的問題是什麼。
擴充套件
這樣的框架不僅適用於較難知識或技術的說明，我還發現在一些框架和開源專案的說明中有所體現，他們會直接引用一開始別人基礎的實現邏輯，然後說明其中的問題，推導到他們升級的原因，從而說明他們新技術或者新設計的優勢，整體下來一氣呵成。
容易被忽略的注意事項
在搭建文章結構，還有一些別的注意事項，我想做一些提醒
不同平臺內容量各不同
首先在搭建文章結構之前，你應該確定這個文章想要釋出在什麼地方。在不同地方釋出的時候，內容量是不一樣的。我經常能在一些公眾號的推文標題看到 “萬文長字，分析 xxx 技術” 又或者是 “看這一篇就夠了 xxxx” 然後點進去嘩啦嘩啦非常的長，在手機上觀看極為不友好。
所以，針對與不同的平臺，你在設計的時候需要考慮內容的不同，當內容過長時進行拆分。比如，針對一個特別系統的設計分析，你可以拆分成專欄的形式進行謀篇佈局，將原本的內容拆分成為幾個小部分，然後在前後增加銜接的內容，從而形成一個體系。
我在寫部落格的過程中，也經常會分析一些成體系的內容，將他們拆分後歸類到一起，對於讀者來說更加友好，每次看的不多，理解沒有負擔，而又在一起，相互只有有聯絡。
程式碼如何展示更優雅
不要截圖！不要截圖！不要截圖！
重要的事情說三遍。我一開始寫部落格並且到後面有很長一段時間都是在截圖，特別是對於一些原始碼分析。當時的想法是，截圖一張圖片能放下大段大段的程式碼，不用佔用很多篇幅。直到有讀者向我反饋問題：圖片看起來有時候不清晰，太小或太大，最大的問題是無法複製貼上，沒有辦法進行搜尋。所以，從那之後我就基本告別截圖了。
開源有外鏈
如果是對於開源的程式碼分析，記得加上外鏈，能方便使用者迅速定位到程式碼段，找到原始方法進行追蹤。
可執行的教程要完整
如果你給出的是一個教程或者一個可以執行的完整示例，請一定要保證完整性。我無數次會發現從網上複製過來的程式碼無法使用，而一些部落格沒有留言功能，最後一點點寫才發現，哦，原來對方忘記上傳了其中某個方法的實現，而這個方法非常關鍵....
開原始碼分析可縮量
針對於開源的程式碼，沒必要整段整段的複製，一方面確實篇幅太長了，佔用了文章大量的資源。並且讀者不好閱讀，其實我們在分析程式碼的時候往往抓住的是主線，所以其中沒有圍繞主線的部分你可以手動刪除並做註釋，縮量之後會讓整個結構更加清晰。
總結
當然，說了這麼多，對於寫作的框架還有很多，這裡只是列舉出我現在常用的一些，希望對你有所幫助。當然，寫作框架固然非常重要，但是它需要你慢慢去總結和摸索。所以對於不同的人來說，我給出以下的建議：
- 剛開始寫作的同學：無論是什麼，只要你去寫就好，儘量追求易懂。
- 寫作了一段時間的同學：請嘗試運用一些技巧和框架去讓你的行文更加流暢，讓你的文章能被更多人點贊。
- 寫作了很久的的同學：慢慢積累自己的寫作思路，建立起成熟的體系，形成自己的風格，能快速建立你形象，從而收穫越來越多的粉絲。