程序員寫好技術文章的幾點小技巧

簡介：其我自己並不喜歡寫字，以前寫的幾篇文章，涉及的話題自帶流量，因此閱讀量多了一些，談不上有多擅長。不過我仍是分享一下我本身寫文章時用到的一些小技巧吧，但願對你們有幫助。

做者 | 門柳
來源 | 阿里技術公衆號

去年成爲了內網技術分享平臺的年度做者，受邀寫一篇關於「如何寫好文章」的文章。我自己並不喜歡寫字，去年寫的幾篇文章，涉及的話題自帶流量，因此閱讀量多了一些，談不上有多擅長。不過我仍是分享一下我本身寫文章時用到的一些小技巧吧，但願對你們有幫助。

一 最重要的是內容

和全部人強調的同樣，好文章最重要的是要有好的內容，好的技術文章要讓讀者有益。若是你想寫一篇爆款文章，可是又以爲沒有內容可寫，那就不要勉強了，放下筆，合上電腦，有這個時間不如去看書打遊戲。

如何讓本身有源源不斷的內容可寫？這與平時的積累有關，多閱讀，多思考，多寫做，真正的技巧無外乎這些。方法論層面的東西再也不贅述，我重點講幾個具體的小技巧，直接「授之以魚」。

二 優秀技術文章的特色

1 閱讀量 ≠ 文章質量

有些文章標題比較吸引眼球，有些話題自帶流量，有些內容的受衆比較廣，因此有很高的閱讀量，但這並不表明文章自己的質量。

前幾天無心翻到一篇《超長用戶行爲建模在躺平家居內容推薦中的應用實踐》，我以爲寫得不錯，可是內容我徹底看不懂，是專業領域的文章，受衆很少，有上千的閱讀量就已經很不錯了。可是另外一篇《如何畫好一張架構圖？》就有超過 3W 的閱讀量。固然反例也有不少，就再也不列舉了。我本身寫的幾篇講技術細節的文章，就沒有講技術對比、討論技術發展的文章閱讀量高。內容越專越細，能讀下來的人就越少，但並不表明文章質量不高，反之亦然。

技術文章盲目追求閱讀量和點贊數不是件好事，因此第一個小建議就是不要太關注閱讀量和點贊數，寫的文章對別人有用，纔是最有成就感的。至於除了閱讀量和點贊數之外，還有什麼指標能夠衡量一篇文章的好壞，歡迎你們留言討論。

2 文章要長長長長長長長長長長長長長長長（也別太長）

我翻了幾篇阿里技術公衆號裏閱讀量較高的文章，各類話題都有，風格差別很大，可是有一個共同點：文章寫得很長。這並不表明文章寫了不少字就是好文章，背後的真實含義是：好文章的內容足夠豐富。

內容豐富詳實，這是一篇好文章的必要條件。還有一個條件是要包含真正有價值的內容，不能含太多水分。

提供一個小技巧：若是你寫了一篇文章可是以爲內容很單薄，能夠先當成一篇筆記存起來，等有了更豐富的積累以後再整理成文章。擴展文章內容的方法，並非添加無心義的空話套話，而是根據文章探討的問題延展開來。

好比說介紹本身解決的一個老大難 Bug，可能真正修改的代碼並無幾行，把過程講出來也不過寥寥幾段。這時候你就能夠再分析一下 Bug 存在的緣由，爲何一直拖到如今，再思考一下如何避免這類問題，遇到同類 Bug 怎樣快速排查。這樣本身想問題的角度更全面了，文章內容也更豐富了。

好比你想介紹一項本身在學的新技術，發現本身寫的東西其實就是官方文檔的簡化版，去重以後幾乎什麼都不剩了。這時候不要再繼續抄文檔了，把本身的思考總結先記下來，繼續學習技術，持續記錄新的內容，有更全面的瞭解以後，再寫文章。

3 清晰的敘事結構

優秀的技術文章，結構必定是清晰的，有可能目錄就表明了某個技術體系，或者表明瞭解決問題的思路。

優秀的內容 + 清晰的結構 = 好文章

能把技術問題講清楚，就很考驗表達能力，這是大部分程序員比較欠缺的。對於技術類文章，常見套路也很少，我簡單介紹兩類吧：

• 線性敘事，逐步推動：適用於介紹排查問題的過程、分享設計思路、介紹項目的迭代進展。
• 結構化敘事，層層展開：適用於講規劃、作總結、畫大圖、介紹一整套技術方案。

4 線性敘事，逐步推動

對於這類文章，讀者是應該按順序一段一段看的，寫的時候腦海中模擬讀者的視角來寫。這類文章的小技巧就是：模擬讀者視角，設定一條主線，有節奏的向前推動。和講故事差很少，每一步的推動要有邏輯，要保持思路不要斷掉。

有時候稍微加點趣味也是不錯的，好比《Flutter Widget 和 CSS 佈局原理 PK》這篇文章，目標是分析 Widget 和 CSS 的設計差別，我把文章寫成一場比賽，先介紹參賽選手，而後分了 5 個 Round 開始 Battle，而後是 Love&Peace，最後一個 Happy Ending。

另一篇《記一次完整 C++ 項目編譯成 WebAssembly 的實踐》介紹了本身嘗試新技術的心路歷程，先介紹背景，再分析需求作拆解，而後講嘗試了什麼方案，遇到了什麼坑，又繼續試其餘方案，最終是什麼結果。讀起來比較流暢。

5 結構化敘事，層層展開

除了按順序看的，還有不按順序看的文章嗎？有的，尤爲在專業的技術文章裏很常見，大部分是「總-分」的結構，先講總體框架，再分章節介紹各個部分。

比較常見的是那種總結型的文章，好比《平臺建設的7大問題：螞蟻AI平臺實踐深度總結》和《救火必備！問題排查與系統優化手冊》，就是翻閱性質的書，能夠通讀一遍，也能夠只看其中一段，以後遇到相關的問題，根據目錄跳着閱讀。

對於文思泉涌的人，能夠一口氣把整篇文章寫完。但實際狀況是，不少時間被碎片化，可能還要引用一些專業內容，可能須要查資料，寫文章的過程會被中斷。這類文章不是一口氣寫完的，是先搭架子再填充完整的。其實寫起來也很簡單：先想好標題，再劃分好目錄結構，再一段一段的填充內容，最後再潤色一下鏈接部分。文章能夠不按順序看，也能夠不按順序寫。

我本身寫的《關於瀏覽器、Weex、Flutter 的比較和思考》這篇文章就是先劃分好了目錄，再一點一點填充的，寫文章的時間跨度也比較長，想起來一點寫一點。

線性敘事是個鏈表，結構化敘事是樹。

三 提高寫做技巧

我初高中的時候比較喜歡看閒書，偶爾本身寫點東西，可是我做文考得並不高，這裏大言不慚地聊一下怎麼寫做文吧哈哈哈哈哈。只講怎麼寫技術文章，並不能提高任何文學功底，但說不定能幫你避開一些小坑。

1 碎片化記錄，結構化整理

大部分人的問題是不知道該寫什麼，即便已經有足夠的積累，有明確的話題要寫，也不知道該如何下筆。這就要靠平常的積累了。

在平時工做的時候，能夠建個文檔庫，把平常的一些瑣碎的想法記錄下來，隨時寫隨時存。我是用手機的便籤 App 隨手記東西，比較喜歡它的語音轉漢字功能，工做相關、生活相關，隨時隨地想起任何話題均可以記錄下來。

在有了明確話題，準備寫文章以前，先把各類碎片化的記錄收集起來，造成一份「素材」文檔，而後梳理文章脈絡，把素材應用進去。操做起來很簡單，剛開始的時候會遇到先後不通暢的問題，那就不要直接複製素材的內容，從新換個表達方式寫出來。多練習練習就行了。

2 刻意練習，先寫再改

有了素材以後，平時能夠專門練習寫做能力，先寫一小段話，明確的描述一個觀點，而後不斷修改。其實寫週報就是一個很好的鍛鍊機會（如今不要求寫了，自行練習），練習把作的事情描述清楚，說話的方式簡單點，不要用太多高大上的詞彙。最關鍵的部分在於：寫完花五分鐘再改一遍！讀一下是否通順，有沒有把問題講清楚。反覆修改纔是提高寫做技巧的關鍵。

用週報舉例有點奇怪，畢竟是郵件類型的東西，和寫文章差異很大，仍是不要亂改週報了，改本身之前寫的文章吧。找一篇本身之前寫的，內容很不錯可是寫得不太行的文章，重寫一遍！這個過程既溫習了技術，又鍛鍊了寫做技巧。不要以爲無聊浪費時間，親測頗有效的。

3 注意排版和語法細節

對於不拘一格的程序員來講，寫出來的文章沒有排版，就是屢見不鮮。不須要追求高級的排版技巧，稍微注意一下幾個常見的問題就行了。

正確使用標點符號（沒想到我竟然在講這個……）

大部分的文章裏就只有逗號和句號，逗號和句號也是看心情隨意劃分，鍵盤上按到哪一個是哪一個。其實還有單雙引號、頓號、冒號、分號、歎號、破折號、省略號、書名號、中文括號「」【】等等…… 使用方法能夠去網上搜，這部分我以爲問題很常見，就單獨多講了兩句。對了，中文文章要用全角標點符號，儘可能不要混用英文標點符號。

添加多種展示形式，可參考 GitHub 的 Markdown 語法

若是全都是普通段落，看起來太平，能夠加上無序列表、有序列表、段落引用、表格等等。行內排版能夠加上粗體、斜體、代碼標記等，偶爾還能夠用刪除線。

其餘還有一些小的建議：

• 區分大標題小標題，分配的均勻一些，最多不要超過三層。
• 每一個章節的長短也儘可能均勻一些，太長的內容就拆個小標題。
• 重要數據給出明確的數據源，擴展信息給出資料鏈接。
• 中英文混寫的時候，在中間加一個空格。
• 注意英文的大小寫，尤爲是專業名詞的縮寫。
• 英文喜歡長句，複合從句一層套一層；中文追求言簡意賅，錯落有致，能夠多加標點符號，把長句分隔開。
• 寫完以後通讀一遍，儘可能少寫錯別字……

最後一個小技巧：多用圖片。即便圖片裏只有文字，信息量也遠超文字。

然而我這篇文章並無加不少圖片，由於這並非一篇技術文章，你們在講技術原理的時候要多用圖片，一圖勝千言！

四 寫在最後

最後一個小建議：文章寫多了就能夠逐漸造成本身的風格，讓全部文章都保持某種共性。

好比我每篇文章最後都會發招聘信息！

歡迎優秀的你加入淘系技術部-跨平臺技術團隊！一塊兒打造靠譜的跨平臺方案。這裏有手淘核心鏈路在使用的 DinamicX、淘系的 H5 容器、Weex、淘寶小程序容器。淘系的基礎架構、研發支撐是隔壁的兄弟團隊，咱們在普遍的支撐新零售的業務。技術深度足夠深，業務場景足夠豐富，歡迎優秀的小夥伴來一塊兒搞事情，手淘跨平臺技術團隊歡迎你的加入！（請聯繫 hanks.zh@alibaba-inc.com ）

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。