程式設計師如何像寫程序一樣寫作?

經過了整整三個月的努力，我終於將這本已在心中醞釀了很久的專欄寫完了。這件事真是一種很奇特的經歷，整個過程既讓人覺得很糾結，很惶恐，也令人感到很興奮，很快樂。我個人認為，在如今的網際網路上，人們只要能善用搜尋引擎，基本上就可以找到自己想要了解的任何信息了。因而在這個時代，寫書的目的已不應該只是單純地普及知識了，它應該更多地表現作者自己的一些觀點和經驗。因為只有這種個性化的東西才是任何人工智慧的產物所無法替代的，這些東西當然未必正確，但它能刺激思考，引發討論，使人沉澱，而這些恰恰是如今網際網路上所缺少的。所以，我希望通過這個專欄來介紹一下個人對Markdown這種寫作方式的看法和使用經驗，以此來拋磚引玉，引起大家對Markdown更多的關注，進而將軟體開源的精神推廣至寫作領域。畢竟，文字作品才是我們人類開發時間最長，數量最多的一種「軟體」。

點擊圖片 立即購買 

為什麼要寫該專欄？

寫這專欄的最初念頭源自於一次在Facebook上的抱怨。由於我自己是一個Markdown的重度使用者，在日常做筆記、寫文章、翻譯書籍時，經常需要搜尋各種使用Markdown寫作的解決方案。而與此同時，市面上的各種博客、論壇、雲端筆記服務也都紛紛加入了對Markdown的支持，這說明使用這門標誌語言的用戶並不在少數，但我卻驚訝地發現自己市場上竟然找不到一本介紹Markdown的專著。於是就在Facebook上分享了下面這個想法：

我是覺得markdown寫作可以延伸出很多東西啊，寫論文涉及LaTeX、Mermaid等，製作電子書涉及gitbook ，建構博客涉及Hexo，居然沒人寫本書！可惜了……

很自然地，這條想法分享的下面就有朋友留言建議我「不如你來寫吧」。雖然當時我只是在表達自己需要這樣一個專欄，最好請某位專業人士來寫一本，但與朋友的討論讓我重新審視了自己所分享的這個想法。這個想法實際上說明了我為什麼喜歡用Markdown來寫作的原因：第一，Markdown是開源軟體，符合開放、自由、專注於任務，便於同行協作的工作哲學。第二，Markdown符合「數據與呈現樣式、用戶界面分離」程序設計思維。第三，Markdown的純文本特性使我們可以想管理程式設計師原始碼一樣管理自己的文字作品。總結一下，就是Markdown可以讓人們「像寫程序一樣寫作」，這讓我意識到寫這樣一本專欄的意義已經不僅僅是介紹一門輕量級的標記語言，而是在推廣一種強調自由、開放、合作的價值觀和方法論了。而這種價值觀和方法論原本就是我多年以來一直在堅持的，如今既然看到沒有人寫一本關於Markdown的專著，不如就自己來為它的推廣做點事吧。專欄內容介紹？

在這本專欄中，我以一篇本科畢業論文的寫作過程為導引，介紹了Markdown在完成論文的規劃、撰寫、修改、發布這些不同任務階段中的應用。全專欄被分成了六個章節和兩個附錄：

第1章 使用Markdown寫作：在這一章中，我們介紹了Markdown是什麼、它有什麼優勢和劣勢以及它所倡導的寫作理念。需要說明的是，這一章的內容是為對Markdown一無所知的朋友準備的。如果讀者自認為已經對Markdown有所了解，或者不想糾纏於技術概念，想快點進入「如何使用Markdown」的議題，也可以選擇跳過這一章。第2章 寫作的前期準備：在這一章中，我們首先介紹了幾款值得一試的Markdown編輯器。然後，我們以論文的前期規劃為導引，帶大家學習了使用Markdown的標記來擬定論文大綱、表列論文的參考資料、並通過設定待辦事項來安排寫作的進度。第3章 撰寫一篇論文：在這一章中，我們繼續以論文的正式寫作過程為導引，逐步深入地介紹了其餘主要的Markdown標記，以及它們的具體使用。這其中既會包含用來表示段落、強調、引用、代碼這些基本元素的原生Markdown標記，也會涉及到與表格、圖形相關的擴展標記，以及它們的基本用法。第4章 談談數學問題：在這一章中，我們首先介紹了如何在Markdown文檔中插入$\LaTeX$標記，以呈現數學公式。然後，我們會具體介紹如何用$\LaTeX$標記來描述基本四則運算、二項式方程、矩陣運算以及集合運算等數學問題。第5章 作品的審閱與維護：在這一章中，我們圍繞著如何」像維護程序項目一樣維護Markdown項目「的議題展開了一系列的討論。首先，我們介紹了一款可以讓人們更專注於文字內容審閱和修改的Markdown編輯器。然後，考慮到Markdown的應用目前尚不夠普及的現實問題，為了讓更多的人參與作品的審閱，我們為大家介紹了一款專用於轉換標記語言格式的工具。最後，為了從時間維度上對項目的修改進行管理，我們也對如何用git版本控制系統對Markdown項目進行管理和維護，做了一個基本介紹。第6章 Markdown的其他應用：在這一章中，我們為大家介紹了如何用Markdown製作演示文稿、線上電子書以及撰寫博客。集中展示了Markdown作為一種寫作方式的廣泛適用性。附錄A Makefile簡易教程：在這篇附錄中，我們為大家介紹了Makefile文件的基本寫法，以便搭配第5章中介紹的格式轉換工具批量地將Markdown文檔轉換成其他格式的文檔。附錄B 了解一下Node.js：考慮到本專欄介紹的gitbook和Hexo都要基於Node.js運行環境來部署，而這個運行環境如今已經形成了如此龐大的軟體生態系統，我認為有必要用一篇附錄專門介紹一下Node.js以及它的安裝和配置。開源運動簡介

在讀者正式開始閱讀本專欄之前，我還希望對開源運動做一個簡單的介紹。從本質上來說，軟體的開源事實上是針對軟體工程問題提出的一個解決方案。而說起軟體工程這檔事，我相信計算機和軟體工程專業的學生應該都不陌生，我們早年間都背下來過一些流水線式的項目開發流程。

首先是在項目定義階段要做可行性分析、需求分析這些事，再來進入到開發階段要做概要設計、詳細設計、設計實現等步驟，最後是維護階段的運行與維護。仿佛軟體開發就像《摩登時代》裡的工廠流水線，分工明確、井然有序。目的是讓程式設計師成為流水線上的工人，使他們成為生產機器中的一個螺絲釘，無需創意、無需個性，只要夠熟練就行。很多大型企業的開發項目也確實是按照這個路數走的，很多程式設計師被戲稱「碼農」也正是這個原因。

但是，等我工作了若干年之後再來看這套工程管理模型，感覺這基本上就是個「計劃經濟」。首先，絕大部分軟體在開發初期根本不會有那麼多人參與，通常是兩三個人要做所有的事情。分那麼多階段，那麼多工序是沒有意義的。再來，就算是有了一定規模的公司，他們會讓很多人參與一個項目，往往都是為了維護已有的軟體，程式設計師的主要任務是維護該軟體的版本，並在此基礎上開發新的版本，在這種情況下，他們其實已經有了現成的開發框架，這些人只需要根據特定的需求將該框架填充成具體的專用軟體即可。

對於原框架來說，這更像是增加了一個特性分支。例如說，JetBrain團隊開發了一款名為IntelliJ IDEA的通用IDE，而Android Studio則又是專用於Android開發的IDE，它就是基於IntelliJ IDEA開發出來的。我們可以將它視為IntelliJ IDEA項目的一個分支。這更像是某種意義上的維護工作，它的可行性，需求是一目了然的，也不需要概要設計，只需要按照其原有的插件體系把功能實現即可。然後，bug修復才是這個項目的主要工作。所以，如何讓那麼多人一塊有效地，有序地發現bug、報告bug、解決bug成為了主要問題。

上世紀的七十年代和八十年代爆發了兩次所謂的軟體危機[1]，那時候的許多軟體項目都出現了預算超支、發布時間嚴重拖延、質量管理缺失等問題。大量的項目因此而失敗，問題很嚴重，以致於北約這樣的組織都要專門開會來討論這個問題。但這些高高在上的人物討論出來的東西就是我們上面所說的軟體工程理論。按照《人月神話》作者佛瑞德·布魯克斯（Frederick P. Brooks）的說法，這需要大量的銀彈、人員來支撐，只有大型企業，科研機構才能做到。當然對於這些機構來說，這套理論確實能解決一些問題。尤其在網際網路時代來臨之前，這似乎也是我們唯一的選擇。

但大型機構都存在官僚主義的問題，組織繁雜、溝通成本高昂、開發效率低下，隨著時間的推移它們往往都會離人們的實際需求越來越遠，就像是那些中世紀大教堂，高高在上、脫離現實地定期發布信息，內容龐雜而滯後，對於其周邊的、下遊的開發者和中小軟體開發是毫無幫助。於是Linux之父林納斯·託瓦茲（Linus Torvalds）在獨自開發Linux內核的過程中走出了一條新的道路：開放源碼、社區協作。

簡單來說，就是由軟體項目的創始人開發出一個不成熟的初始版本，然後將其丟到一個開發者社區中，讓其在開發者自發性的修改和分享中自然生長。最後，項目創始人會根據其生長情況將自己認可的部分納入到項目的主分支中。這種亂中有序的組織形式讓Linux項目獲得了巨大的成功，給軟體開發的工程管理提供了一種新的實踐經驗。

無獨有偶，上世紀九十年代末期，網景公司[2]在與微軟公司的瀏覽器大戰中敗下陣來，面臨著公司的生存危機。他們決定試試開源的方式。埃裡克·雷蒙（Eric Raymond）就是網景公司當時的策略顧問，他在幫助網景公司的過程中根據自己的新的寫出了他那本聞名天下的代表作：《大教堂與集市》。這本專欄為開源運動奠定了理論基礎，它系統闡述了網際網路條件下的協作模式，同行審評的優勢，回答了《人月神話》中提出的銀彈問題，人員管理成本問題。如今，微軟、蘋果這些曾經的大教堂都紛紛加入了開源領域。開源作為軟體工程的另一種組織形式已經毋庸置疑。

最後需要提醒的是，開源運動和理察·斯託曼（Richard Stallman）領導的自由軟體運動[3]不是一回事。開源運動更多的是一種軟體工程的管理方式，雖然也強調開放源碼、免費分享的自由精神，但並沒有太強烈的道德要求。而自由軟體運動則更像是一種宗教性的意識形態運動，他們對於「確保用戶使用軟體的自由」有著一種近乎苛刻的道德要求，譬如，他們會要求所有基於自由軟體開發的產品都不僅要開放源碼，還必須要允許用戶修改該產品軟體的源碼，或變更其硬體的使用方式，讓用戶真正地享有「自由」，這難免讓人覺得有一些烏託邦式的理想主義。而在我個人看來，如此激烈的主張在客觀上反而會給原始碼的分享帶來了不少的阻力。

使用Markdown寫作

在這一章中，我們將會對Markdown做一個概念性的簡單介紹。具體來說，我們會討論Markdown是什麼、它有什麼優勢和劣勢以及它所倡導的寫作理念。需要說明的是，本章是為對Markdown一無所知的朋友準備的。如果你自認為已經對Markdown有所了解，或者不想糾纏於技術概念，想快點進入「如何使用Markdown」的議題，也可以選擇跳過本章內容，直接從下一章開始閱讀。但是，如果你想更完整地了解我對這門技術的觀點，還請你稍微花點耐心讀一下這一章的內容，畢竟正如一千個人的心中有一千個哈莫雷特，對於同一門技術，每個人的理解也都略有不同。

Markdown是什麼？

Markdown是約翰·格魯伯（John Gruber）1  與亞倫·斯沃茨（Aaron Swartz）2  於2004年共同開發的一門輕量級標記語言（Lightweight Markup Language，簡稱LML）。也就是說：首先，Markdown是一種標記語言，可以用任意的文本編輯器來進行輸入和修改，並以純文本的格式保存在計算機中。

其次，這是一種「輕量級」的語言，這意味著相對於RTF、HTML、TeX這些格式更豐富的標記語言來說，Markdown的格式更為簡單易用，也更接近於自然語言。這讓它更適合用來寫作和分享。格魯伯們開發這門語言的目的就是為了鼓勵人們先使用一種易讀易用的純文本格式來編輯並存儲文檔，然後再根據實際需要將文檔轉換成(X)HTML、docx和PDF等格式。Markdown在設計上非常重視可讀性。換句話說，Markdown的設計目標之一是要讓人類能直接從字面上對其進行閱讀，不需要太多精力學習一些格式化指令標記（譬如RTF與HTML）。

1  約翰·格魯伯是一位來自美國賓夕凡尼亞州的作家、博客編者、用戶界面設計師及Markdown發布格式的發明者。2  亞倫·希勒爾·斯沃茨是一位著名的美國電腦程式員、企業家、作家、政治活動者和網際網路黑客主義者。他參與開發了RSS網上信息源發布格式、Markdown文本發布格式、知識共享組織、web.py網站開發框架，同時是社交媒體Reddit的聯合創始人。

事實上，Markdown最初的實現只不過是格魯伯參考現行電子郵件的標記格式和一些早期的標記語言（譬如Setext、Texile等），編寫出的一個可將用Markdown語法編寫的文檔轉換成有效的、結構良好的(X)HTML格式的Perl腳本程序：Markdown.pl。該腳本既可以單獨使用，也可以被用作Blosxom這類博客系統的插件，或者BBEdit這類編輯器的文本過濾器。但隨著時間的推移，Markdown已經被許多人用Perl或其他程式語言重新實現，市面上陸續出現了許多不同版本的Markdown實現。

同時，人們也在Markdown基本語法的基礎上開發出了許多額外的功能，例如表格、腳註、列表以及代碼塊等。這其中有些功能已經偏離了這門語言最初的實現，帶來了語法規範上的含糊不清，這些問題促使Markdown的標準化問題被提上了議程。當然，值得一提的是，作為Markdown的創立者，格魯伯並不贊成完全標準化，他認為：「不同的網站（和人們）有不同的需求。沒有一種語法可以讓所有人滿意。」

以我寫這本專欄時3  所查到的資料，Markdown標準化的最新進展是，2016年3月發布的RFC 7763和RFC 7764這兩份文件。其中，RFC 7763文件從原始變體引入了MIME類型text/markdown。而RFC 7764文件則討論並註冊了MultiMarkdown、GitHub Flavored Markdown(GFM)、Pandoc、CommonMark和Markdown等不同的實現版本。

Markdown的優勢與劣勢

如今，Markdown的使用者早已不只是寫程序文檔的程式設計師，它在國際上已經受到越來越多編輯和寫作者的青睞。用Markdown來寫作和編輯文章在網絡時代有著超乎想像的優勢。下面，我們就來具體討論一下這些優勢：

語法簡單易讀：由於Markdown的語法簡潔明了，且在寫過程中基本不需要鍵盤以外的其他設備操作，讓人們可以更專注於寫作本身，這將帶來很大的效率提升。關於這一點，我稍後會在下一節介紹Markdown的基本寫作理念時做更進一步的討論。文本格式存取：在我個人看來，能以純文本格式來處理並存儲文檔是Markdown最大的優勢。我們後續介紹的大部分優勢都與這一特性有著或多或少的聯繫。簡而言之，Markdown的純文本特性給它帶來了極強大的兼容性，我們可以用任何文本編輯器來處理Markdown文檔，不用擔心不同編輯軟體之間的橫向兼容問題（譬如微軟的Word和蘋果的Pages之間的兼容），以及這些軟體自身升級所帶來的縱向兼容問題（譬如舊版Word就打不開新版Word的默認格式docx）。
另外，如果你使用的作業系統是Linux/Unix或MacOS的話，還有大量針對文本的系統工具可以用（譬如diff、sed等），這些工具都會給文檔的存取、搜索與傳輸帶來極大的方便。便于格式轉換：由於Markdown是以純文本的形式存儲在計算機中的，這也賦予了它很強的可編程性，人們可以輕鬆地為其編寫各種格式轉換工具。經過了許多人的共同努力，到目前為止，我們已經可以輕鬆地將其轉換成(X)HTML、PDF、epub、mobi、docx等格式了。關於這方面的內容，我們將會在第四章中詳細討論。利於網絡協作：有過遠程辦公經驗的人都知道，我們在網絡協作過程中首先會遇到的通常是平臺相關性問題，譬如你用的是Windows上的Word。我用的是MacOS上的Pages，他用的是Ubuntu Linux上的WPS，經常會彼此打不開對方的文件，或者打開了對方的文件，卻由於各自作業系統上支持的中英文字體不同而導致排版慘不忍睹，甚至完全亂碼。這一切都會由於上面提到的Markdown的純文本特性而得到解決。

再來就是網絡協作中會遇到的另一個問題，那就是協作成員可能會同時對同一份文件做出不同的修改，這就需要用到版本控制。市面上似乎所有的版本控制系統，無論是CVS、SVN還是Git，優先支持的都是純文本格式的文檔，我們完全可以像管理程序項目一樣對Markdown文檔進行各種版本操作。關於這方面的內容，我們將會在第五章中進行更為詳細的討論。

除此之外，由於Markdown本身就是個開源項目，任何人都可以對其實現進行修改、重構和擴展，所以有人用它寫程序項目的文檔，有人用它構建博客平臺（譬如Hexo等），有人用它製作電子書（譬如gitbook等）。總而言之，在使用了Markdown之後，我們可以將程序設計領域中的開源思想完全應用於寫作領域，實現在網際網路範圍內的同行審閱、分享與討論，以改善作品質量、促進整體進步。當然，任何人、事、物都會在展現其優勢的同時呈現出一些劣勢。而且優勢和劣勢通常都來自於同一個特性，是優勢還是劣勢完全看這個特性所發揮的面向。下面我們就來看看Markdown具有那些劣勢，或者說它不適合被用來做哪些事：國內使用尚不普及：雖然這些年Markdown在國內受到了越來越多的重視，但在一些關鍵領域，比如大部分出版社還是會要求你提供Word版本的稿件，哪怕是一些出版計算機書籍的出版社也是如此，這就說明這種寫作方式的普及遠未達到理想的程度。不適合用來做排版：Markdown的語法設計是為了讓人們專注於寫作內容，所以並不適合用來做複雜的排版，比如各種印刷字體的設置、複雜的表格、圖片的文字環繞等。這些需要我們去學習一些專用於排版的工具，譬如LaTeX，用它們搭配Markdown使用。周邊工具學習成本較高：Markdown的周邊工具非常多，譬如用于格式轉換的pandoc、用於排版設計的LaTeX、用於發布HTML格式電子書的gitbook、用於構建博客的框架Hexo等。每一項工具都可以被視為一門獨立的技術，如果全都要掌握，面面俱到，那麼學習成本將是非常高昂的。所以，我們要根據自己的需要有選擇地進行學習。所以說，所有的機制、框架和工具最終都要落實到具體的使用上，而「如何使用」基本上是使用者根據應用場景所做的判斷。一件工具是發揮它的優勢，還是呈現出它的劣勢，就全憑使用者如何做出判斷了。基於Markdown的基本寫作理念在介紹完Markdown的優勢和劣勢之後，我們再來進一步討論「為什麼應選擇使用Markdown來寫作」這個問題。首先，我想請大家先一起來回顧一下：在使用紙和筆為主的時代，我們是怎麼寫作的。相信那個時代還並不遙遠。大家應該都還記得我們的寫作大致上是按照以下步驟來進行的：
在上述過程中，我們在每個步驟中都不需要去考慮其他步驟的事。譬如，在寫大綱的時候，我們只需要是思考各章節的標題是什麼？不需要考慮各章節的標題應該是什麼字體、字號和顏色。在送給老師和編輯審閱的時候也不需要考慮他們用什麼電腦，電腦裡裝了什麼系統。排版編輯也不會在排版設計階段抱怨我們那些既自以為是，又混亂不堪的排版增加了他太多額外的工作量。但這些問題在我們使用了Word或Pages這樣的文字處理軟體之後卻都一一成了常見問題，這是為什麼呢？原因就在於這些文字處理軟體的功能太強大了。是的，軟體功能太強大也會帶來問題。因為這些軟體功能會誘惑我們在寫作的同時兼顧很多事，這些事會對寫作的步驟形成幹擾。譬如，這些功能會誘惑我們在編寫章節標題的時候去考慮它們的字體、字號和顏色。在寫各章節內容的時候就會去考慮段間距、行間距、文字對齊或表格樣式等。但是，寫作是一個需要保持思維連續專注的工作，如果你總是同時在思考好幾件事，寫作思維就會被打得支離破碎，這是非常影響寫作質量的。當然，我們確實可以運用自控力讓自己先專注於當前的寫作步驟。但會讓我們有意識地用到自控力這件事本身就證明了這些功能的幹擾。畢竟我們在用筆和紙寫作的時候，連想都不會去想到這些，除非你是在用一套水彩筆寫作。Markdown的簡單易用就是讓寫作回歸於紙和筆的狀態，儘量排除一切工具的幹擾，讓我們專注於寫作本身。除了能讓寫作回歸其本真，提高我們對寫作的專注力之外，使用Markdown寫作的另一個基本理念是：像寫程序一樣寫作。Markdown的設計完全符合我們在編寫程序時所要遵守的一些原則：每次只做好一件事：如前所述，Markdown只專注於與寫作相關的事情。避免平臺依賴，確保可移植性：Markdown以純文本格式存儲，不依賴於任何作業系統和編輯平臺。不重複發明輪子：使用Markdown編寫的文本文件可以作為其他程序的輸入數據，這確保了我們可以使用現有的工具對Markdown文件執行進一步的處理，譬如用LaTeX排版，用Hexo發布博客等。避免安裝一些巨大而臃腫，卻百分之八十功能永遠都不會用到的昂貴軟體。

基於這些原則，我們就可以將所有可用於程序開發的軟體設計和工程經驗運用到文字創作上，更好地發揮計算機賦予我們的優勢，讓我們的寫作過程更為規範，更符合網際網路時代的工作形態。

在文中，我們首先介紹了Markdown的概念、設計理念和標準化的過程。然後，我們羅列了這門標記語言的優勢和劣勢。最後，我們基於這些優勢和劣勢闡述了基於Markdown的基本寫作理念。

簡而言之，Markdown是一門專為寫作而設計的、自由開源的輕量級標記語言。它的語法簡單明了，非常接近於人類的自然語言，有助於我們將注意力集中於寫作本身。另外，由於它的純文本特性，使它具備了非常好的開放性和可編程性，這讓我們可以像使用程式語言一樣用它來進行寫作，即先寫完內容，再用其他各種工具來對其進行處理。而且在整個寫作過程中，我們都可以運用之前作用於程序開發的軟體工程思想來管理寫作進度，執行版本控制以及處理作品的發布問題。從下一章開始，我將會以一篇專業論文的產生過程為例來具體介紹Markdown的使用，看看像編程一樣寫作的過程究竟是怎樣的一種體驗。

先領券再購買 優惠多多哦

- END -

🎤

分享時刻

你對markdown的體驗如何？

截止8月30日，留言+轉發朋友圈

抽取1名讀者

➤ 邀請贈書，邀請10人關注公眾號異步圖書10天，即可獲得圖書一本！

點擊表單申請

異步圖書

聊聊圖書背後的故事