程式員如何像寫程式一樣寫作？

https://www.epubit.com/columnDetails?id=CL6c695f34d7aec

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

https://www.epubit.com/columnDetails?id=CL6c695f34d7aec

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文檔中插入$\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以及它的安裝和配置。

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的使用，看看像程式設計一樣寫作的過程究竟是怎樣的一種體驗。

https://www.epubit.com/columnDetails?id=CL6c695f34d7aec

先領券再購買 優惠多多哦

- END -