程序員如何像寫程序同樣寫做？

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

01 爲何要寫該專欄？

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

我是以爲markdown寫做能夠延伸出不少東西啊，寫論文涉及LaTeX、Mermaid等，製做電子書涉及gitbook ，建構博客涉及Hexo，竟然沒人寫本書！惋惜了……

很天然地，這條想法分享的下面就有朋友留言建議我「不如你來寫吧」。雖然當時我只是在表達本身須要這樣一個專欄，最好請某位專業人士來寫一本，但與朋友的討論讓我從新審視了本身所分享的這個想法。這個想法實際上說明了我爲何喜歡用Markdown來寫做的緣由：

• 第一，Markdown是開源軟件，符合開放、自由、專一於任務，便於同行協做的工做哲學。
• 第二，Markdown符合「數據與呈現樣式、用戶界面分離」程序設計思惟。
• 第三，Markdown的純文本特性使咱們能夠想管理程序員源代碼同樣管理本身的文字做品。

總結一下，就是Markdown可讓人們「像寫程序同樣寫做」，這讓我意識到寫這樣一本專欄的意義已經不只僅是介紹一門輕量級的標記語言，而是在推廣一種強調自由、開放、合做的價值觀和方法論了。而這種價值觀和方法論本來就是我多年以來一直在堅持的，現在既然看到沒有人寫一本關於Markdown的專著，不如就本身來爲它的推廣作點事吧。

02 專欄內容介紹？

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

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

03 開源運動簡介

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

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

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

對於原框架來講，這更像是增長了一個特性分支。例如說，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]不是一回事。開源運動更多的是一種軟件工程的管理方式，雖然也強調開放源碼、免費分享的自由精神，但並無太強烈的道德要求。而自由軟件運動則更像是一種宗教性的意識形態運動，他們對於「確保用戶使用軟件的自由」有着一種近乎苛刻的道德要求，譬如，他們會要求全部基於自由軟件開發的產品都不只要開放源碼，還必需要容許用戶修改該產品軟件的源碼，或變動其硬件的使用方式，讓用戶真正地享有「自由」，這不免讓人以爲有一些烏托邦式的理想主義。而在我我的看來，如此激烈的主張在客觀上反而會給源代碼的分享帶來了很多的阻力。

04 使用Markdown寫做

本章提要

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

05 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等不一樣的實現版本。

3 即2019年03月。

06 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等。每一項工具均可以被視爲一門獨立的技術，若是全都要掌握，面面俱到，那麼學習成本將是很是高昂的。因此，咱們要根據本身的須要有選擇地進行學習。

因此說，全部的機制、框架和工具最終都要落實到具體的使用上，而「如何使用」基本上是使用者根據應用場景所作的判斷。一件工具是發揮它的優點，仍是呈現出它的劣勢，就全憑使用者如何作出判斷了。

07 基於Markdown的基本寫做理念

在介紹完Markdown的優點和劣勢以後，咱們再來進一步討論「爲何應選擇使用Markdown來寫做」這個問題。首先，我想請你們先一塊兒來回顧一下：在使用紙和筆爲主的時代，咱們是怎麼寫做的。相信那個時代還並不遙遠。你們應該都還記得咱們的寫做大體上是按照如下步驟來進行的：

• 在腦海中構思做品的總體方向和大體內容。
• 在一張紙上列出做品的大綱，以肯定各章節的標題。
• 以大綱肯定的各章節標題來編寫做品內容，寫出初稿。
• 而後將初稿的複印件送給相關人士審閱，收集反饋。
• 根據審閱者的反饋修改做品，寫出最終稿。
• 將最終稿交給出版社進行排版設計，並出版做品。

在上述過程當中，咱們在每一個步驟中都不須要去考慮其餘步驟的事。譬如，在寫大綱的時候，咱們只須要是思考各章節的標題是什麼？不須要考慮各章節的標題應該是什麼字體、字號和顏色。在送給老師和編輯審閱的時候也不須要考慮他們用什麼電腦，電腦裏裝了什麼系統。排版編輯也不會在排版設計階段抱怨咱們那些既自覺得是，又混亂不堪的排版增長了他太多額外的工做量。但這些問題在咱們使用了Word或Pages這樣的文字處理軟件以後卻都一一成了常見問題，這是爲何呢？緣由就在於這些文字處理軟件的功能太強大了。是的，軟件功能太強大也會帶來問題。由於這些軟件功能會誘惑咱們在寫做的同時兼顧不少事，這些事會對寫做的步驟造成干擾。譬如，這些功能會誘惑咱們在編寫章節標題的時候去考慮它們的字體、字號和顏色。在寫各章節內容的時候就會去考慮段間距、行間距、文字對齊或表格樣式等。可是，寫做是一個須要保持思惟連續專一的工做，若是你老是同時在思考好幾件事，寫做思惟就會被打得支離破碎，這是很是影響寫做質量的。固然，咱們確實能夠運用自控力讓本身先專一於當前的寫做步驟。但會讓咱們有意識地用到自控力這件事自己就證實了這些功能的干擾。畢竟咱們在用筆和紙寫做的時候，連想都不會去想到這些，除非你是在用一套水彩筆寫做。Markdown的簡單易用就是讓寫做迴歸於紙和筆的狀態，儘可能排除一切工具的干擾，讓咱們專一於寫做自己。除了能讓寫做迴歸其本真，提升咱們對寫做的專一力以外，使用Markdown寫做的另外一個基本理念是：像寫程序同樣寫做。Markdown的設計徹底符合咱們在編寫程序時所要遵照的一些原則：

• 每次只作好一件事：如前所述，Markdown只專一於與寫做相關的事情。
• 避免平臺依賴，確保可移植性：Markdown以純文本格式存儲，不依賴於任何操做系統和編輯平臺。
• 不重複發明輪子：使用Markdown編寫的文本文件能夠做爲其餘程序的輸入數據，這確保了咱們可使用現有的工具對Markdown文件執行進一步的處理，譬如用LaTeX排版，用Hexo發佈博客等。避免安裝一些巨大而臃腫，卻百分之八十功能永遠都不會用到的昂貴軟件。

基於這些原則，咱們就能夠將全部可用於程序開發的軟件設計和工程經驗運用到文字創做上，更好地發揮計算機賦予咱們的優點，讓咱們的寫做過程更爲規範，更符合互聯網時代的工做形態。

**本文小結 **

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

簡而言之，Markdown是一門專爲寫做而設計的、自由開源的輕量級標記語言。它的語法簡單明瞭，很是接近於人類的天然語言，有助於咱們將注意力集中於寫做自己。另外，因爲它的純文本特性，使它具有了很是好的開放性和可編程性，這讓咱們能夠像使用編程語言同樣用它來進行寫做，即先寫完內容，再用其餘各類工具來對其進行處理。並且在整個寫做過程當中，咱們均可以運用以前做用於程序開發的軟件工程思想來管理寫做進度，執行版本控制以及處理做品的發佈問題。從下一章開始，我將會以一篇專業論文的產生過程爲例來具體介紹Markdown的使用，看看像編程同樣寫做的過程到底是怎樣的一種體驗。

先領券再購買 優惠多多哦

- END -