Readme 驱动开发

中文翻译：陈磊 AReverie
英文原文：Tom Preston-Werner

我最近听到很多关于测试驱动开发、行为驱动开发、极限编程和SCRUM 、站立会议 以及其他一切如何开发出更好的软件的各种方法论及技术，然而除非开发出来的软件满足使用者的需求，否则都是一纸空谈。我换种说法吧，对于错误规格的完美实现毫无价值可言。基于同样的原则，一座没有书卷而华丽修缮的图书馆也近乎无用。如果你的软件没有解决正确的问题或者根本没人知道它到底干嘛的，那可就不好玩了。

很好，那我们怎么解决这个问题呢？实际上比你想的要来的简单，并且其重要都足以单独列出一段。

先写 Readme

首先，就像前面说的，在你动手写任何代码、测试、行为或者情景甚至任何东西前。别急别急，我明白我们都是程序猿，不是技术文枪手！但这就是你没想明白的地方。为一个软件写 Readme 着实非常有必要性。在给你的软件写点什么东西前，你根本不知道你要编写什么样的代码。在人人喊打的瀑布型设计和人见人爱的敏捷开发之间，我们似乎漏了点什么。别误会，瀑布型设计代价太大。它能把一个细致入微的庞大系统变成一个细致入微却全盘错误的系统。当初砍掉它是个正确的做法，但做法却矫枉过正。如今我们的项目里只有短小、糟糕的文档甚至完全不见踪影。你能想象有些项目完全没有 Readme 吗！

简直难以接受！在成堆的技术规格和完全没规格之间，必然会有个平衡点。那个平衡点就是朴素简明的 Readme。

将 Readme 驱动开发（下文简称 RDD）区别于文档驱动开发（下文简称 DDD）十分重要。RDD 可以理解成 DDD 的一个有限版本或子集。通过将你的设计文档精简成一个旨在介绍软件的单个文件，RDD 能帮助你免于重蹈 DDD 而出现的瀑布型开发过程中出现冗长而过分细致的规格。同时，它能帮助你保持库的精简和模块化。这样一个简单的方法能帮助您免去繁琐的流程保证项目朝着正确的方向前进。

通过写第一个 Readme，您能受益于以下这些显著的优势:

• 最为重要的一点是，您给于了自己一次重新审视项目，又无需每次为了改变主意而去修改代码而花去开销的机会，例如整体应该如何组织、公用 API 里到底应该包含哪些东西。还记得您第一次写自动化测试代码，意识到揪出全部的错误从而防止那些问题悄悄跑进代码里去吗？在项目真正编码前写一个 Reame 的感觉是如出一辙的。

• 为了明确应该实现什么而去写 Readme 会产生一些副产品，您会得到一份写的非常棒的文档。当您在项目伊始，也就是兴奋度和动机处于最高的阶段，写一个文档会十分容易。事后再补 Readme 将是一种绝对的障碍，并且您会发现遗漏了许多重要的细节。

• 如果您与一群开发者一起协同工作，将会发现会从 Readme 收益颇多。如果其他成员在您尚未完成项目前便可以读到这份 Readme，他们将大可放心的在将与您项目有交互的代码上开始工作。如果没有预先定义好的接口，团队只能顺序地编码或者面临重新实现大量代码的窘境。

• 基于白纸黑字的讨论将会容易的多，而在一个没有任何成文内容的讨论话题上，事情往往会演变成争论不休。把建议的解决方案写下来这样一个简单的行动，代表了一个具体的想法，从而能被讨论，迭代发展下去。

把给您项目写 Readme 的过程当作一种真正的创造活动吧，这是您充满闪光的想法应该被表达的地方，这份文件的本意应当是阐述您的创造力和表现力。Readme 应当是您代码中最为重要的一个文档，适当的做法就是首先写 Readme。