線上圓桌 | 對於技術寫做，你有什麼要說的？

Hello，歡迎你來到主題爲「技術寫做」的線上圓桌活動，我先來介紹下本身：我是沸點運營 -- 清蒸，本次活動邀請了掘金社區最有表明性的 7 位做者來談談他們對「技術寫做」的見解，本次圓桌的初衷不在於幫你得到一篇 1k+ 贊 or 10w+ 閱讀的文章而是讓你知道這個社區高贊高閱讀高粉絲的做者們是如何看待「技術寫做」，而他們在當中的哪些小技巧使他們在社區內得到技術寫做「成功」。

本次圓桌活動嘉賓均爲社區高粉絲、高閱讀、高贊做者，做爲社區內容生產核心，這些做者們更瞭解這個社區基調，知道什麼內容更適合社區，若是你想在掘金和他們同樣得到技術「成功」，不妨聽聽他們怎麼看待這些問題。

先來看下他們的合影

*注：按暱稱首字母排序，下同

嘉賓介紹

來和掘金小夥夥伴們介紹下本身 😊

超人汪小建：Hi，我是超人汪小建，已寫做 5 年，文章包括算法、人工智能、大數據、各類開發等類型文章，已出版《Tomcat 內核設計剖析》，即將出版一本算法書籍，同時也陸陸續續在寫 AI 相關的書。

Hollis_公衆號Hollis：我是 Hollis，一個我的技術博主，微信公衆號Hollis（ID：hollischuang）負責人，我的博客技術博文閱讀量數百萬，技術文章寫做 3 年多。

J_Knight_：你們好，我是一名剛滿三年的非科班 iOS 開發者，從事寫技術博客已經有兩年多了，在掘金積累了 11000+ 名粉絲。

劉志軍：你們好，我叫劉志軍，一名 Python 開發者，從大學開始一直有記筆記、寫博客的習慣，堅持了七年多，寫做成爲了我生活中一部分。

劉望舒：從 2011 年開始在 CSDN 寫博客，瓜熟蒂落的成爲了 CSDN 博客專家，而後經過 CSDN 吸引了出版社編輯，出了兩本暢銷書《Android 進階之光》和《Android 進階解密》，同時也開通本身的公衆號[劉望舒]，平均閱讀量在 2000+。

守候i：你們好，我是守候，前端開發者，三年工做經驗，寫做應該是有一年半了。

冴羽：我是冴羽，一個優秀的高冷的帥氣的優雅的 Web 前端攻城獅，一個靠 JavaScript 系列、JavaScript 專題系列、underscore 系列、ES6 系列沒有發家也沒有致富的掘金用戶。

圓桌開始

經過寫做，你得到了什麼呢？

超人汪小建：提高探索能力、思惟能力、表達能力、毅力吧。

Hollis_公衆號Hollis：和超人汪小建相似，除了提高表達能力，我還提高了本身的技術能力，同時也收穫了了不少粉絲的承認。

J_Knight_：我從寫做中收穫的不只僅是平臺的粉絲以及影響力，更多的是學習能力，語言描述的能力以及力求把事情作到最好的品質。詳情請看我最新的一篇文章：我從寫技術博客中收穫到了什麼？- J_Knight_

劉志軍：寫做給我帶來很多收穫，它能幫我從新整理思路，經過對外分享得到更多關注和交流機會，還有工做機會和一些出版社的邀請等，同時，由於遇上了好時代，經過寫做還能得到一些額外的收入。

劉望舒：正如我自我介紹的同樣，出版兩本 Android 暢銷書的我經過暢銷書，受邀出席了不少技術大會並發表了演講，認識了不少 Android 界的知名大咖和技術專家，也讓不少 Android 開發者知道了我。能夠看出，經過寫做我獲得的不只僅的技術上的提升，也產生不少積極的、質變的化學反應，更幫助了不少開發者。

守候i：和他們相比，個人寫做時間有些短，但我在寫做的這一段時間，最大的收穫就是和其餘的前端開發者交流學習；以及本身的對各個知識點的一個學習，整理，總結。日後也會堅持寫做，但願你們多多支持。

看來各位寫做收穫頗多，大家的寫做初衷又是什麼呢？

超人汪小建：發表我的看法，創建我的品牌。

Hollis_公衆號Hollis：知識記錄與分享，提高我的影響力。

J_Knight_：個人寫做初衷只是單純地記錄一些學習筆記和讀書筆記。到如今也仍是這個目的，只不過隨着粉絲數增多，對博客質量上的要求愈來愈高了。

劉志軍：最先寫做沒想太多，就是把它看成一個備忘工具，早期我是把東西記在本地，可是放本地不方便在其它地方查看，後來就把內容直接放在了網上，成爲了一名 blogger，一開始寫的東西其實很爛，隔段時間回過頭來看的時候甚至本身也看不懂，這也是不少人剛開始寫做時存在的問題，由於咱們沒有考慮讀者的感覺，自嗨型創做。如今寫做除了備忘以外，仍是一個思考的過程。

劉望舒：每次看到網上的文章時，看的彆扭，就本身寫了，看本身寫的是最舒服的，並且還能不斷改進。

守候i：原本這個只是當作我的筆記使用的，可是後來想着把筆記分享出去，和別人交流學習下，以及有一個技術博客，簡歷也加分，就開始寫文章了。

冴羽：但願我作前端的幾年裏(將來不管是作後端、仍是作管理、仍是擺個鐵板燒小攤都是對前端的一種遠離)，能給業界留下一點微小的東西。

小結：看來，你們的寫做初衷比較相似，都是分享整理內容和打造我的品牌😊

在清蒸看來文章分系列文章和和單篇文章，寫單篇文章的話，你是如何進行選題呢？

延伸下，你們都在寫《用 Vue 作一個仿 xx 》、《關於 Javascript 閉包你該知道的一切》等常見話題文章時，隨着文章基數的增多後來的文章若是沒有新的切入點很難得到高閱讀和高點贊，因此如何一個切入某個點進行單篇技術寫做是一個難點。

超人汪小建：除了寫書以外，我寫單篇文章選題主要來源有三個：

• 工做相關，平時在工做中負責的事情，以爲有價值的東西我會提煉出來寫成一篇文章。
• 零碎的靈感，平時靈感一來想到一些主題或感想，就會我會給本身的微信發要點記錄下來，後面有空時就會看本身給本身發了那些idea，進行寫做。
• 讀書暢想，由於我每一年都要求本身看三四十本書以上（書房已經塞了幾百本書），因此看了不少書後本身會有不少我的看法或者總結，因而能夠寫成一篇文章。

清蒸：嗯，和工做相關的內容不容易「撞題」 ，內容的獨特性來源於工做和書籍。

Hollis_公衆號Hollis：工做中遇到的問題，學習中的總結，讀者粉絲們提的問題等。

清蒸：看來將工做中遇到的問題文字化是文章的一大來源。來看看 J_Knight_ 怎麼看這個問題 🎙️

J_Knight_：個人博客除了一些源碼解析的文章以外，都是和當時的業務方面的學習相關的。有些突如其來的業務需求涉及到的技術點可能很是陌生，這個時候就能夠選擇和這一方面相關的主題來學習。 因此個人不少博客都不是從零開始寫的，都是源於本身平時的一些學習筆記。學習筆記成型以後再不斷修改和添加本身的思考以後，博客差很少就成型了。

清蒸：正如 J_Knight_ 說的，讀書筆記是一個很好的切入點，能夠慢慢學會去總結和整理知識點。

劉志軍：沒有刻意去選題，由於我不是職業寫做者，個人文章素材通常源自於工做或者經過平時閱讀習慣積累，逐漸造成本身的素材庫，有空了就從素材中挑一個主題寫。

清蒸：志軍老師和小建大佬的來源相似呀，聽聽守候對此有啥見解？

守候i：我以爲得知道本身目前對什麼技術主題有興趣，以及掌握了或者學習過的一些技術主題，再進行寫做。切忌選擇一些不熟悉的主題。至因而不是系列文章，我的以爲沒太多的關係，但須要注意的一點就是選題不適合太普遍，太普遍可能會致使文章過長，讀者會累，寫得也累，也會亂。

清蒸：守候說了一些選題的禁忌點，冴羽有啥補充呢？

冴羽：雖然我歷來不寫單篇，但我以爲要寫文章就寫本身想寫的東西、或者最近學習的東西、或者從項目中思考和實踐的東西，這些課題不須要你想，他們就自動冒出來了。

小結：比較一致的見解，文章的選題來自於工做點滴和平時的書籍閱讀

如何處理技術文章正文部分題外話--問題來自以前問題收集 中「卻把清梅嗅」的提問

不少技術博客中不可避免會加入一些寫做者本人的情感（或者叫題外話），這些文字有時會被說 「廢話多」、「囉嗦」，可是有時做爲過分的段落，它可以讓讀者更有代入感轉接到下一個知識點，這個度如何把握？

Hollis_公衆號Hollis：控制字數和段落。不超過兩段，不超過 500 字。

清蒸：控制篇幅好像是個不錯的方法，可是具體到文章，大概是要控制佔比了。不過，J_Knight_ 好像有不一樣的見解 🎙️

J_Knight_：首先我以爲題外話，或者帶有本人情感的話應該是越少越好，甚至是應該徹底沒有的，這類話會顯得做者不夠專業，並且會影響文章總體的專業性，讓整篇文章的質量大打折扣。一篇內容專業的文章被一些帶有情感色彩的話和題外話拖累是很讓人痛心的。 並且並非說必定要用這類話來做爲過分或者讓讀者有代入感。相反，用客觀的，專業的文字做爲過分也是徹底能夠的。

清蒸：志軍老師也有不一樣的意見，🎙️

劉志軍：不必刻意把握，文章的背後是一個真人，不是 AI，人是有溫度的，有情感的，若是你在寫做過程當中那些所謂的「囉嗦」是發自心裏的，那麼讀者是能感覺到文字中流露出的情感，讀你的文章就感受是在和做者交流。若是你是給文章刻意加戲，讀者就顯得你囉嗦了。

清蒸：🤔理解爲文章要出自真心不知恰當否，聽聽望舒對這個問題的見解。

劉望舒：我認爲技術文章仍是少參雜一些我的的情感，就如同寫書同樣，儘可能要言簡意賅，能一筆帶過的，毫不拖拖拉拉。

清蒸：好像守候也是和望舒、J_Knight_ 同樣的見解？

守候i：是的，關於我的情感，我的建議是：能避免則避免，沒法避免就一句話說完，而且著名是我的的建議，見解等。情感觀點也切勿過於偏激，我的主義。好比就如同火鍋湯底可辣可不辣，喜歡辣湯底火鍋的能夠表達本身的喜愛，可是不建議對不辣湯底的火鍋起批鬥性的言論。

清蒸：冴羽，你怎麼看待題外話這個問題？

冴羽：emm，我歷來不寫。

小結：對於我的情感抒發類的題外話，大部分的做者選擇的是能不寫就不寫。

寫源碼解讀或者理論性比較強的文章時，如何兼顧生動有趣呢？-- 問題來以前問題收集 中「弗蘭克的貓」& 「RecoReco」的提問

Hollis_公衆號Hollis：講故事，比喻，畫圖

清蒸：畫圖的確是一個很是棒的方式，圖解類的文章一直都是很受你們歡迎的，圖片相對文字更直觀、形象，閱讀者能更好地理解到你講的意思，同理比喻也是。J_Knight_ 有話要補充 🎙️

J_Knight_：這兩類文章的寫法差異蠻大的，我在這裏分別說一下。

• 一. 源碼解讀類的文章： 這一類文章必定避免不了對大段代碼的分析和解讀，因此要注意爲了不讓讀者感覺到枯燥乏味，須要在講解源碼的以前先大體介紹一下這個源碼或框架的用途和使用方法，讓讀者對它的功能有一個初步的認識。 而後最好能夠提供一個該框架的架構圖，再分別介紹一下架構裏面每一個成員或模塊的做用。這是爲了讓讀者瞭解一下源碼的結構。 並且在解讀源碼的時候，最好還要用圖或者日至輸出來讓讀者真正用眼睛看到這段代碼的執行效果是什麼。 最後，若是再能說出框架做者爲何這麼設計的理由的話（這麼設計好處在哪裏，若是不這樣設計的話會有什麼問題），博客的質量就會明顯上升一個檔次。我以爲若是作到這幾點的話就能夠避免讀者感受枯燥乏味了。 各位能夠參考我寫過的一篇源碼解讀：MJRefresh 源碼解析。這篇文章在講解代碼的同時，還提供了不少形象的截圖來配合代碼的解析。

• 二. 理論性比較強的文章： 這類要避免枯燥乏味的話相對容易一些，簡單說就一句話：理論結合實際，抽象轉爲具體。 不能單單地長篇大論你的理論，還應該用真是可用的 Demo 或者一段代碼來驗證這些觀點，並且最好是可視化的，也就是有圖或者日至輸出，讓讀者真切體會到這個理論有什麼用途，這個理論的意義在哪裏。 各位能夠參考我寫的一篇關於設計原則的文章：面向對象設計的六大設計原則。這篇文章除了介紹這六大原則以外，還針對這些原則提供了 Demo 和 UML 類圖；並且還對比了遵循和不遵循這些原則的區別在哪裏。

清蒸：很詳實地介紹了下源碼和理論性文章的撰寫方法，志軍老師對理論性的文章有啥見解？

劉志軍：對於理論性的東西，最好用比喻手法，用一些來自於某些生活場景的比喻，好的比喻能讓讀者秒懂，我曾經寫過幾個例子，關於代理和反向代理，還有 Python 裝飾器的概念，在知乎有超過 1000 贊。另外，一圖勝千言，日本的不少技術圖書能把高深的內容用圖解的方式呈現，就是很好的例子

清蒸：和 Hollis 的見解一致，望舒好像有不一樣的見解？🎙️

劉望舒：拿 Android 系統源碼來講，其實我也想寫的生動有趣，可是事實上這種理論和生動有趣徹底的不搭邊，硬湊只會讓文章失去原有的光彩。

清蒸：看來生動有趣不是全部的內容均可以作到的，😊，聽聽守候怎麼看生動有趣？

守候i：兼顧生動有趣給我感受，第一要避免一大段文字。第二要時不時的出現些圖片，讓文章生動些。兼顧這兩點，給我印象深入的就是《碼農翻身》了，裏面的文章，引用了大量的動畫，圖片，讓文章變得更加的有趣。記得還記得有看過一篇文章是師生問答形式，可是文章貌似刪除，找不到了。這兩種形式能夠參考下。也是我學習的一種方式。

清蒸：《碼農翻身》一本很不錯的書，閱讀本文的小夥伴有機會能夠閱讀下，看看冴羽對源碼解讀怎麼看 🎙️

冴羽：源碼解讀自己就是讀者難以經過一遍閱讀就能理解的東西，我只能作到源碼理解過程當中，讀者可能遇到的問題，可能會想到的問題都寫上本身的理解，而後……而後我就無論了……

清蒸：🤔Get 到的點是，分享本身的見解幫助他人理解

小結：生動有趣能夠經過圖來完成，可是有時候難以免的要「枯燥」地講解源碼和理論，將本身的理解呈現給閱讀者以做參考便於他們理解便可。

有深度的技術文章受衆少，如何兼顧技術深度和高閱讀呢？-- 問題來以前問題收集 中「wujunze」& 「閔仙森」&「sea_ljf」的提問

Hollis_公衆號Hollis：儘可能用通俗的話語把高難的技術表述清楚，按部就班的介紹，配合代碼，圖片，甚至動畫，音頻等。

清蒸：輔助圖、音頻形式，按部就班由淺入深地來說解。

J_Knight_：「陽春白雪，下里巴人」，有深度的技術文章受衆少是一個很是正常的現象，我我的沒有寫過很是有技術深度的文章，可是對於這類文章如何提升閱讀，在這裏說一下我本身的見解。 其實高閱讀無非源於兩點：

1. 標題看上去比較吸引人，容易讓人點進去看
2. 不少人能夠在文章裏面有所收穫，願意去分享這篇文章

分別說一下上面兩點：

1. 標題看上去比較吸引人 標題看上去吸引人有兩個緣由：
   1. 主題不偏離如今的熱門主題太遠
   2. 用一些修飾性的辭藻加以修飾（標題黨除外） 首先就是主題應該不能太偏。若是太偏，可能多數人都不會去點擊，好比一個.NET的主題和Flutter的主題的熱門程度確定是不同的。 其次是適當加一些引人入勝的辭藻，可是不建議太過，由於會影響總體的專業性。
2. 不少人能夠在文章裏面有所收穫 因此到這裏就是既要有技術深度，也要讓人有所收穫。我認爲是最難的一個部分：將晦澀難懂的理論知識讓大部分人容易理解是很能體現出做者寫做功力的。我這裏有兩個技巧：
   1. 提供足夠的背景知識
   2. 善於利用比喻和聯想 提供足夠的背景知識： 你須要將讀者想象成一個徹底外行的人，你須要提供TA須要先了解的一切背景知識，用於構建你後面所講解的知識體系。 善於利用比喻和聯想： 即便是有了背景知識可讓讀者在理論層面理解，可是這還不夠。由於這個時候讀者可能仍是不會應用這些理論。因此最好使用現實中的例子或者也能夠想象出一個生動的例子去模擬這個理論模型，讓讀者能夠對這個理論有更形象的認識。

清蒸：很棒的寫做技巧提點，志軍老師對這問題有另外的解讀 🎙️

劉志軍：人更願意接收不須要思考的東西，這也是深度技術文不那麼受關注的緣由。若是想得到更高的閱讀，仍是取決於於做者對技術的理解程度，你對某個技術的理解越深，你就越有可能用淺顯易懂的語言來表達。

清蒸：志軍老師說的挺對的，結合我自身，有些深度內容恨不得被人分解成零零碎碎我不用思考去閱讀，💦個人我的閱讀習慣很差，好在我這樣的讀者有對知識點理解深入的人來輸出內容 😊看看望舒看待這個問題的。

劉望舒：我想做爲寫做者，確定是但願高閱讀。當寫做者技術的不斷提升時，大部分仍是但願會去寫一些有深度的文章，隨着愈來愈多的人進入高級開發，這些有深度的文章也會有這良好的閱讀量。另外，一些新技術的入門深度不高，可是會獲得高閱讀，能夠寫一寫，畢竟技術不只僅要追求深度，一樣也要兼顧廣度。

清蒸：酒香不怕巷子深，時間會給好的內容帶來流量，這話不假，雖然緩慢但終歸會被人接收、傳播。冴羽好像有不一樣的見解。

冴羽：很難作到，因此不要想了。我學習本身想學的，我寫本身想寫的，而後我分享出來，若是能對閱讀這篇文章的人能有所幫助，我很開心，閱讀量什麼的，就順其天然吧

清蒸：順其天然也不錯，守候怎麼看？。

守候i：曲高和寡，既然文章是有技術深度，那麼看得懂文章的人就少，閱讀數會受到影響。要兼顧技術深度和高閱讀，這個彷佛很難作到。能夠的就是儘量作到在一篇文章裏面，用生動有趣的方式，把深度的技術通俗易懂的表達出來，讓更多的讀者容易讀懂，閱讀數就會有一個提高，這個就彷佛又回到上一個問題了（如何兼顧生動有趣呢？）。

清蒸：確實，深度內容對人的理解要求高，對應的受衆基數小，閱讀量也就不如普及性文章來的高。

小結：對於高閱讀和深度的平衡，嘉賓的見解並徹底相同，清蒸的見解偏向望舒、冴羽，我的以爲擺正心態，專一寫做便好，時間會分好壞。

有什麼寫做用的工具安利嗎？

冴羽：我也想知道看看其餘嘉賓怎麼說？

超人汪小建：寫文章主要仍是內容吧，工具只是提高效率，markdown 效率就很高，展現代碼和排版都方便，並且多數網站都支持。因此只須要有道雲筆記 + chrome 的微博圖牀插件就能很高效了。

Hollis_公衆號Hollis：mweb--「Mweb」是一款 Mac Markdown 應用，因其豐富的功能和強大易用性俘獲大批忠實用戶，經過「Mweb」，你能夠完成寫做、記筆記、靜態博客生成等工做。官網地址：傳送門

J_Knight_：寫做用的工具我主要使用下面幾個：
    - Markdown 筆記：Evernote 或有道筆記。這兩個筆記都是支持多平臺的，更新很是方便，不受電腦的限制，用手機就能夠；並且也沒有電腦客戶端的限制，由於能夠用 web 服務。
     - 圖牀：圖牀我最初使用的是七牛，可是後來域名被回收了，就改成用阿里雲的 OSS 服務了。這個服務是按照流量收費的，不過個人流量還不是很高，半個月只用了幾分錢，感受還好。
     - 動圖製做：有的時候展現 Demo 的時候會須要用動圖。我使用的是 PicGif 軟件（Mac 平臺）。首先是用 Mac 自帶的 QuickTime 把 Demo 的操做錄下來，而後再用 PicGif 編輯便可。

劉志軍：我沒有用太多的工具，就用 sublime 在本地寫，存在 GitHub 的私有倉庫，文章都是基於 markdown 寫的，這樣我不須要花太多時間在排版上。工具越簡單越好，我是 markdown 重度使用者。

劉望舒：時序圖推薦用 visio 2013 ,其餘的圖推薦使用 ProcessOn。

寫做有什麼注意的事項同你們分享的嗎？例如：排版、代碼展現？

Hollis_公衆號Hollis：參考必定要原文地址，尊重別人的知識產權。

清蒸：嗯，產權這個很重要，清蒸在這裏呼籲下：若是你發現別人的文章非原創，來源於他人且未標註轉載出如今他的專欄下，記得告訴官方~ 感恩 ❤️

J_Knight_：我認爲寫做的注意事項有一下幾點：

1. 大標題的層級最好不要超過 3 層，否則會增長讀者的閱讀成本
2. 若是有並列的事項最好用 1，2，3 或者原點開頭豎着排列起來，而不是橫着寫。
3. 解釋性的語言最好用 markdown 的引用語法來標註，方便用戶直接區分哪些是正文，哪些是輔助性的語句。
4. 代碼塊和針對該代碼的講解的高度加起來不能超過一個屏幕的高度。這是一個閱讀體驗的問題：若是代碼塊很長，超出了一個屏幕的高度，讀者可能就會來回上下滾動屏幕，很影響閱讀體驗。並且這個時候讀者也不方便看到代碼的講解，也可能會來回上下滾動屏幕，也是比較糟糕的體驗。所以我建議的是將代碼段和這段代碼的講解能夠在一個屏幕的高度下徹底展現出來，這樣的話讀者只須要移動眼球就能夠同時看代碼和其對應的講解了。
5. 若是文章的理論性知識過多，最好須要提供 Demo 展現或者日誌輸出，讓讀者對理論有更加直觀的認識。
6. 段與段，尤爲是每一個部分之間要有承上啓下的過渡語句，否則讀者會有一種很突兀的感受，影響閱讀體驗。
7. 文字的描述要經得起推敲，切忌生搬硬套，最好是用本身的話將資料或者其餘文獻裏的文字表述出來。也就是說你須要真的理解了你所寫的才能夠。

清蒸：很棒的一些寫做小總結，劃重點，記下記下 📒

冴羽：我會遵照中文技術文檔的寫做規範 ，其餘的我就無論了。

清蒸：阮老師的這個寫做規範挺完整的。

最後一問，如何對抗本身不想堅持寫做的惰性？-- 問題來以前問題收集 中「豌豆花下貓」的提問

超人汪小建：

• 培養習慣：培養寫做習慣，習慣培養起來了幾天不寫文渾身難受。
• 制定計劃：能夠給本身制定短時間、中期、長期目標，好比要求本身一個月寫滿五篇文章，半年寫出某個領域的系列文，兩年完成一本書籍的編寫。
• 預留固定時間：一篇質量較高的文章寫完其實平均得四個小時，因此寫做時間必須有保證。好比能夠預留一三五晚 8 點到 10 點爲寫做固定時間，週末天天預留 3 個小時。
• 持續輸出：找一個平臺，好比掘金、CSDN、公衆號等，保證起碼周更頻率，有了粉絲和讀者的反饋鼓勵，也能讓本身更有動力。

Hollis_公衆號Hollis：逼本身，好比我在作公衆號，給本身定了一個目標：每週都要有原創。這樣就能夠逼迫本身要進行不斷的原創輸出。

J_Knight_：我認爲產生惰性或者拖延的根本緣由是：以爲這件事的執行成本很是大，同時作這件事的收效沒法預期。

回到寫博客這方面上來，不少人不想寫博客或者是沒法堅持的緣由也是相似的：

1. 沒有主題，方向，無從下手
2. 以爲寫博客須要花費太多的時間，並且就算寫了，若是想寫好也是須要費大量的時間和精力
3. 博客寫出來質量上怕保證不了，怕被吐槽。

其實上面這三點在我看來都不是問題：

• 沒有主題方向，無從下手 上面的問題中我也提到過：我所寫的博客其實大部分都來自於我平時的學習筆記。因此只要是我一直在學習，在記筆記，那麼只要是有時間的話，我都會不斷去提煉，去完善，最後造成博客。
• 以爲寫博客須要花費太多的時間和精力 其實從一份筆記到博客的最終造成所花費的時間並非很長，無非就是添加一些寫給讀者的過分性的話，可能還須要加一些配圖，並且排版方面不會太花費時間，由於 markdown 語法已經很完善了，熟練的話能夠立刻理出一篇博客出來。 這裏面須要提一個時間管理方面的問題，不少朋友喜歡利用多個大塊時間來寫博客，或者是一篇博客想一鼓作氣。其實這些想法大可沒必要： 首先大塊時間很是寶貴，應該拿來去學習，去思考。另外，一篇博客寫出來之後，可能次日你看了以後還會以爲有能夠優化的地方。因此我我的建議使用碎片時間來寫博客：能夠用跨平臺的筆記軟件（如今的有道筆記和 evernote 都支持 markdown 語法）來寫博客，有時間的時候能夠打開電腦或者手機來看筆記，想修改的話及時修改，提升時間的使用效率。
• 怕質量達不到要求 其實這一點更不用怕，質量不高或者有錯誤的文章寫出來是有兩個好處的：

1. 可能會有人過來糾正你的錯誤
2. 可讓本身其餘人看到你本身的成長

• 可能會有人過來糾正你的錯誤： 並且可能還會有人看到你文中出錯的時候會耐心教導你，糾正你的錯誤。可是若是你不把你的理解寫出來，可能很長時間都不知道本身理解的是錯誤的，作學問最怕的是不知道本身不知道，因此把問題儘早暴露出來不見得就必定是一件壞事。
• 可讓本身和其餘人看到你本身的成長： 其實博客寫出來以後，也算是對本身學習和成長的記錄。做爲讀者，看到不斷成長的博客就可以感覺到博主的成長和細心耕耘。 不是全部人都是在能力很強的時候纔開始寫博客的，不少人都是從零開始，一點一滴積累，隨着時間的推移，博客質量不斷提升。由於寫做也是一種技能，只要多堅持，多思考的話，能力天然愈來愈好。重要的不是開始的時候怎麼樣，而是你後來的成長了多少。因此不要怕本身博客的質量不夠好，不敢寫。

清蒸：嗯，三點緣由分析的挺到位的，也有相應的應對方法，看看寫做 7 年的志軍老師是怎麼處理的 🎙️

劉志軍：執行力是關鍵，先設置一個可實現的目標，例如保證每週寫一篇文章，寫完後把本身當成讀者，多讀幾遍，直到修改爲本身能理解的樣子。發佈到網上後若是效果不錯，能夠嘗試給網站或者給公衆號投稿，得到更多的曝光機會，這也是一個正向激勵的過程。一旦有了正向激勵，你就有了動力投入更多時間在上面，逐漸造成一種習慣。

清蒸：持續輸出也要有一點的激勵才行，做爲平臺方咱們會努力爲優質的做者和內容提供曝光和流量的，聽守候是怎麼看待這個問題的 🎙️

守候i：我本身的經歷就是，開始寫做了，寫了幾篇，只要有內容可寫，只要有學習到新的知識，或者研究出一些小技巧甚至黑科技類的內容，本身就會作筆記，作了筆記，整理下一篇文章也不會太遙遠了，應該不會出現由於懶而不想堅持寫做的狀況。在習慣寫做了，又有內容寫的狀況下，若是不寫，反而會以爲本身有點事情沒作，渾身會有點不自在。 爲何會出現不想堅持寫做的狀況，我的以爲緣由有三：

1. 工做太忙，沒多餘時間寫
2. 文章被閱讀太少，失去興趣
3. 暫時沒內容能夠寫。 針對前兩個緣由，主要仍是看本身的行動吧，由於時間是能夠擠出來的，文章一開始被閱讀太少也正常，寫的多了，人氣就會提高，若是沒有，可能要思考本身寫的文章是否是哪裏出了問題。最後一個應該是大多數人會遇到的一個問題，也是我如今遇到的問題，沒東西能夠寫了，就多是由於本身學習遇到了瓶頸，或者是本身的學習的知識點一成不變。這個狀況就只能靠本身克服，學到到了新的知識，應該就會有內容可寫了。就我我的而言，之因此不會要求本身一個月要寫多少篇，一年多少篇這些目標，就是由於寫做會受時間，內容而影響。若是強制寫，質量內容通常，反而以爲還不如再等久寫，寫好些。

清蒸：看來守候和 J_Knight_見解相似，看看一直很佛系的冴羽怎麼看待這個問題的。

冴羽：無爲而治，想寫就寫，不寫算了。寫做熱情自己就是一個此起彼伏的過程，想寫的時候多寫幾篇，不想寫的時候就好好休息，刻意要求本身只會增長對寫做自己的恐懼和厭惡，倒不如爲所欲爲，無爲而治。

圓桌結束

本期的圓桌「技術寫做」話題就此就結束啦，別忙走:

• 這邊還邀請了一些你們常見的做者談談他們對技術寫做什麼見解

在 2019.01.09 - 2018.01.18 留意評論區的評論喲

• 若是你的文章得不到曝光也歡迎在評論區貼上地址，讓社區裏的小夥伴幫你分析分析緣由~

只有和閱讀者接觸才知道，才知道什麼是他們想看到的，以及你的文章哪裏須要改進❤️。

延伸閱讀

收錄了社區小夥伴對「技術寫做」的見解

• 《[譯]如何撰寫精彩的技術博客文》 by：幸運兒
• 《寫技術博客那點事》 by：浪裏行舟