first translation

Author: xiaoliwang

.gitignore

@@ -0,0 +1 @@
+.DS_Store

translation/readme_driven_development.md

@@ -0,0 +1,30 @@
+# 自叙文件[^1] 驱动开发
+
+> 作者为 Tom Perston-Werner。
+>
+> 生活在旧金山。[GitHub](https://github.com/) 联合创始人及 [Gravatars](https://en.gravatar.com/) 创始人。他喜欢进行有关创业的演讲，使用 Ruby 和 Erlang 进行编程，在湾区的古老红木森林里骑山地车。
+>
+> "The Readme should be the single most important document in your codebase; writing it first is the proper thing to do."
+
+这些天，我听了很多关于开发更好软件演讲，包括 TDD，BDD，极限编程，敏捷开发，站会和所有类型的方法和技巧。但是除非我们正在开发的软件符合使用者的需求，否则这一切都将无关紧要。让我换一种方式表达，错误规范的完美实现是毫无价值的，就好比一个没有图书的精美图书馆也是一无是处的。如果你的软件解决了一个错误的问题或者根本没人会使用它，这将是一件很糟糕的事情。
+
+既然如此，我们怎么解决这个问题呢？其实比你想象的要简单，但却非常重要，重要到需要有一个专属于它的段落。
+
+在开发前撰写你的自叙文档。
+
+第一，在你写下代码，测试，行为，故事或别的任何东西之前，我当然知道在座的各位是开发人员，不是科技作家，写下一个自叙文档都是必不可少的。否则在你进行开发的时候，你甚至不知道自己在开发什么。介于瀑布流开发和敏捷开发之间，应该有什么是被我们遗忘了的。不要误会我的意思，瀑布流开发需要记录的东西太过详实，详细的系统说明最终只会成为一个错误的详细系统说明。我们确实应该换种方式，但取代它的方式又走向了另一种极端。现在有的项目只有简短的，写的很糟心的文档，或者缺失整个文档。有的项目甚至连自叙文件都没有。
+
+这是不能接受的。一定有一种方式可以介于冗余的说明文档和没有说明文档之间。事实上确实如此，这种方式就是自叙文件。
+
+很重要的一点是区分自叙文档驱动开发和文档驱动开发。前者可以认为是后者的一个子集或者限制版本。通过把你对软件的介绍文档限制在一个单一文件，自叙文档开发使你不会陷入那种被称为文档瀑布综合症的过度冗长或者详尽。与此同时，可以保持你的库尽量的小而且模块化。这些简单的强化措施可以帮助你的项目朝着正确的方向发展，而不需要额外的流程来确保你在做正确的事。
+
+在开发前撰写你的自叙文档会给你带来以下显著优势。
+
+- 最重要的是，你有了一次全面思考整个项目的机会，而不必额外去思考为了代码应该如何组织或者需要提供哪些具体的公共 API 所进行的代码修改。记住那种你第一次写自动测试脚本，并意识到你发现了很多将有可能进入你代码库 bug 的感觉。如果你在写具体代码之前写下自叙文档，你将拥有完全相同的感觉。
+- 作为为了知道你想实现什么而写下自叙文档的副产品，你的面前将会有一份非常棒的文档。你将发现你在项目开始前写下自叙文档会非常简单，因为当时你热情高涨。如果是项目开始后，追溯补充一个自叙文档一定是一个绝对的错误，这个时候你一定会错过所有重要的细节。
+- 如果你正在参加团队开发，你的自叙文档将获取更多里程。如果其他成员在你开发完成前获取了这些信息，他们可以更有自信的在别的项目上与你的代码进行交互。没有定义任何接口，你必须以串行的方式编码或者面对大量代码的重构。
+- 基于文档的讨论也会更简单。没有文档的讨论问题容易陷入无休止和绕圈。写下提议的解决方案这么一个简单的动作能让所有人都有一个明确的想法可以讨论和迭代。
+
+考虑将撰写自叙文档的过程当做一次真正的创作。在这里展现你所有的精彩想法。这份文档应该单独作为你创造力和表现力的证明。自叙文档应该作为你代码库中最重要的文件。一开始写下它将是多么正确。
+
+[^1]: 原文为 [Readme](https://zh.wikipedia.org/wiki/Readme)。