程序员如何像写程序一样写作？

经过了整整三个月的努力，我终于将这本已在心中酝酿了很久的专栏写完了。这件事真是一种很奇特的经历，整个过程既让人觉得很纠结，很惶恐，也令人感到很兴奋，很快乐。我个人认为，在如今的互联网上，人们只要能善用搜索引擎，基本上就可以找到自己想要了解的任何信息了。因而在这个时代，写书的目的已不应该只是单纯地普及知识了，它应该更多地表现作者自己的一些观点和经验。因为只有这种个性化的东西才是任何人工智能的产物所无法替代的，这些东西当然未必正确，但它能刺激思考，引发讨论，使人沉淀，而这些恰恰是如今互联网上所缺少的。所以，我希望通过这个专栏来介绍一下个人对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文档中插入$\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）。

事实上，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等不同的实现版本。

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/articleDetails?id=b88a61f3d77e40519248b37b217c3a0a