就我而言，一年裡我也沒寫出幾篇讓自己滿意的文章。因為寫一篇好的技術文章真的很難。
對於一篇好的文章來說，它有這麼一些要求：
- 構建文章所需的理論體系
- 實踐及程式碼驗證
- 公正又有所偏愛的觀點
又要注意這麼一些事項：
- 反駁錯誤的觀點，但不要限入爭論
- 追求文章對自我和讀者的價值
- 排版和語法高亮
- 注意錯別字和專業用詞
注意：這裡所指的技術文章，不是某個問題的相關回答。而是著重於一些知識要點、架構等等，複雜的文章。
構建文章所需的理論體系
部落格，光只是每天的用到知識點，那麼一星期下來，怕是能記錄滿一本書。寫篇文章可不像寫程式碼那麼輕鬆，首先要理清、整理自己的思路——為什麼當時自己想的是 A 方法，然後才是 B 方法，又或者怎麼找到 C 方法。如果能寫下這個 Debug 過程，讀者也許更能從中學到一些思想。而一本書吧，則是一系列相關的文章構成的合集，再加之以程式碼實踐，以便於讓讀的人能更深刻的理解。寫一本書的時間，可能是要上幾個月，乃至幾年的時間。
將生產領域的程式碼知識整理成體系，那就更加的困難。如在我寫電子書 《Serverless 架構應用開發指南》的時候，我幾乎把能買到的相關中文書籍都買了，以及 Packt 出版社旗下相關的電子書。儘管只是一本託（reng）管在 GitHub 電子書，但是作為我的作品，它在某種程度上代表著我。
寫文章前吧，總是得把思路理清楚。技術文章嘛，歸根還是在做學問，好的技術文章必然是實踐出來的。與一般的八卦文章不一樣的是，技術文章必然需要有資料、實踐基礎，而不是道聽途說或者 Copy/Paste From Google。
可是做起來並不容易，如我在寫《我是如何為技術部落格設計一個推薦系統》三步曲之前的文章時，大概花了一個月的時間，在設計這樣一個推薦系統上。而為了驗證文章的用詞及演算法準確性，又翻閱了一系列的文章和書籍，編寫了兩三個演算法的 DEMO，最後才總算確認下了文章的大概。
實踐及程式碼驗證
有了一個明確的主題和想法之後，我們就需要驗證它的可行性。這就好比是有一些諮詢專案一樣，客戶已經在心裡有想法，但是還需要你去實現。如我在設想 “編輯-開發-釋出” 架構時，花了差不多半個月去用 GitHub + Travis CI 構建一個 DEMO 應用程式。
一般的程式碼驗證，都還是蠻容易的。可是，有些驗證則是感性的。譬如，我們要去驗證 Windows、macOS 和 Linux 哪個更好用的問題，必是要找到這三個作業系統，親自用上個把月的時間。才能知曉我說的： Windows 適合遊戲與工程設計，macOS 裝置進行設計與程式設計，Linux 用作伺服器，這句話到底是不是對的？
結論有了，那麼證據也是要有的。這個時候我們就需要去證明：Mac 上沒有多少遊戲，又缺乏一些專業的工程軟體。然後只得把相關的軟體一個個的羅列出來，一對比。哦，結論真的是這樣的，或者結論可能不是這樣的。
結論不對，評論區裡就會相當的熱鬧。為了評論區的熱鬧，總會有些人丟擲錯誤的結論，“PHP 是全世界最好的語言”。
公正又有所偏愛的觀點
沒有一篇文章能讓所有的人覺得滿意。試圖去寫一篇讓所有人滿意的文章，看上去四不像，結果又讓所有的人都不滿意。
故，一篇文章應該著重於表達作者自己的觀點，觀點應該是有理論依據的，如 “為什麼 Angular 更適合於大型前端應用”，而不是重複的表達 Angular 更適合於大型前端應用。如若不想得罪那些喜歡某個框架的人，在表達的時候需要含蓄一些。如我沒有使用 xxx 開發過大型應用程式的經驗，或者它缺乏這些 xx 的要求。
反駁錯誤的觀點，但不要限入爭論
討論 PHP 是不是最好的語言，本身是沒有意義的。我們只是想去說服對方，而去說服對方，證明自己是的。我們討論的從來不是 PHP 是最好的語言，而是我的觀點是對的。
受教育的標誌是：你可以不接受一種觀點，但你能夠容納它。
容納別人的觀點，並不是一件容易的事。多數時候，可能是我們無法站在對方的角度，因為我們想象不到對方經歷了什麼，比如說，貧窮限制了我們的想象力。
“在網際網路上，沒人知道你是一條狗。”
當然了，“如果批評不自由，則讚美無意義。”做為一個作者，
成為鍵盤俠很容易，只需要接上網路即可。多數的論戰都是沒有意義的，瞭解一件事情的上下文很難，所以多數人懶得去了解。哪怕是你在文中反覆強調了，也是如此。隨後，哪怕是對方後來瞭解了，要在這個時候讓他/她去承認錯也很難。事件就變得越發的糟糕，失控就難以避免。
爭論的時候，雙方都覺得自己的觀點是對的，對方是錯的。只要是有一方覺得，“咦，好像也點道理，但是應該試一試”，那麼這個時候，爭論就此結束了。
至於，自己要不要適當的讓步，便是另外一回事了。
排版和語法高亮
良好的排版，語法高亮樣式，這兩個要素可以上我們披上專業的外衣。對於我而言，保持設計的一致性，而自定義了前端顯示的樣式。
雖然他們並不影響文章的質量，但：
- 好的排版，能提供列好的閱讀體驗
- 程式碼語法高亮，讓你看上去更加的專業。
排版，它是一種細瑣的活動，做好它並不容易。而針對於大部分技術人員來說（也包含我），天生缺乏這種美感。外加之，一般的技術寫作都是先用 Markdown + Git 管理，隨後再使用特定的編輯工具，如 Word、微信編輯器，最後再體驗上容易出現平臺的不一致。我則是使用自制的工具和主題，來統一不同平臺的排版。
配圖。技術文章和長的文章類似，有一個不容易閱讀的問題。改善使用者閱讀體驗的一種方式是，在多個段落之間插入相關的插圖，或許是可以起到視覺過渡的效果。考慮到版權問題，我開始自己去造圖。
程式碼語法高亮，技術文章往旆少不了程式碼來體驗真理。故，程式碼是檢驗理論和架構的標準。在文章中穿插的程式碼，得對讀者友好，而對讀者友好的常見方式是：程式碼語法高亮。這也是我去年，寫了自己的微信公號編輯器的原因，市面上沒有支援微信公號語法高亮的 markdown 編輯器。
注意錯別字和專業用詞
高質量的文章，對於我來說，我的文章一直存在一個錯別字的問題。但是，在不影響文章本身的閱讀，它可能不影響文章的質量。可是關鍵時候，它往往還是影響了文章的質量了。
以前總覺得呢，以後有時間去修改錯別字，可並沒有。但凡是說以後改的東西，在未來基本上是不會改。因為我們覺得，它是可以忍受的，因此優先順序並沒有那麼高。只當我們聊勝於無，才會找一些事情出來。
那些在 GitHub 的電子書經驗告訴了我，讀者往往才是那些更容易找出錯別字的人。我大抵是已經習慣了，這個詞語是怎麼寫的，比如說要分清楚怎麼用連線、聯接，並不是一件容易的事。大部分情況下，我用的是聯接。
Java 8、java 還是 j8，這個問題的答案我想大家都很清楚。作為一個工程師，要最大限度的保證用詞的準確性。如 Java 8 指的是 Java 這門語言的第 8 代，java 指的應該是 Java 語言的命令列工具，j8 是用來罵人的。對於其它語言、構架，如 Python、Ruby 也是類似的，python 是指在 Python 命令列工具，可以進入 Python 語言的命令列械。
追求閱讀量還是自我價值？
追求閱讀量，對於技術部落格和技術公眾號來說是一件可怕的事。出於同樣的追求，未來作者可能會將技術文章變成技術八卦，因為只有熱點和八卦才受人們的歡迎。為了流量和利益，追逐熱點，無非只是將別人的觀點，整理成文章，再看看讀者評論裡的回覆。時間一久吧，怕是終將寫不出有思想的文章。
換而言之，有思想的文章並不是指文章有思想，而是能促進讀者去思考。不可避免地，大部分人都已經習慣不去思考，因此也就閱讀量下降了。
大部分時候，我們並不關心東西南北發生了什麼事，因為離自己太遙遠了。人們一般只關心和自己及身邊相關的事，或者一些可以用於聊天的八卦瑣事。
過去，我也追求文章的閱讀量。在偶然間接觸了 Content Strategy，我才意思到我需要高質量的文章。高閱讀量的文章基本上都有很高的時效性。這篇文章過了幾星期、幾個月，可能沒有一點兒的用處。而高質量的文章，往往不會有這個問題。
當我開始理解高質量重要性的時候，我的思維發生了一些變化。我開始記錄了成長過程中的一些變化，閱讀量一點也不理想。可每當看到這些文章，會冒出一些新的想法。這些文章，大抵是未來的自己而寫的。我不再去刻意地追求閱讀量，開始提升文章的質量。
於是，在平衡閱讀量和質量的時候，我成了一個 “標題黨”。好的標題，往往能提升文章的開啟率的。
結論
嗯，多關注我的微信公眾號（phodal-weixin），獲取更多及時有用的技術知識。