引子
近年来我们听说过很多很多新的开发方式，现在最火热的方式莫过于敏捷开发了；某不是理论学家，对这类理论只求付诸实践；当然，也有很扯的例如鄙厂移动部门搞的所谓敏捷开发，甚至还有不少人叫嚣着某某项目要开源，在某看来很是滑稽。第一他们没有放到github、google code甚至sf.net上去，第二这些项目从未有过文档，至于将来…在某看来也不会有；最后一点可能真是要求高了，完全没有社区氛围。
这就让某陷入了思考——究竟怎么样一种开发方式是如今可取又不太会过时的呢；github的各位为我们提供了许多参考答案，而以下这篇@mojobom(Tom Preston-Werner)写的Readme Driven Development，是某个人比较喜欢的。所以在此某翻译了一些，与大伙分享。
除此之外，@holman也是某比较喜欢的开发者，他在去年发布的一个slide上也有对Readme驱动开发以及inline document(所谓的TomDoc，也是mojobom给取的名字)有所说明。
翻译
2010/08/23 - 旧金山
我最近听到很多关于测试驱动开发、行为驱动开发、极限编程和SCRUM 、站立会议 以及其他一切如何开发出更好的软件的各种方法论及技术，然而除非开发出来的软件满足使用者的需求，否则都是一纸空谈。我换种说法吧，对于错误规格的完美实现毫无价值可言。基于同样的原则，一座没有书卷而华丽修缮的图书馆也近乎无用。如果你的软件没有解决正确的问题或者根本没人知道它到底干嘛的，那可就不好玩了。 很好，那我们怎么解决这个问题呢?实际上比你想的要来的简单，并且其重要都足以单独列出一段。
先写Readme
首先，就像前面说的，在你动手写任何代码、测试、行为或者情景甚至任何东西前。别急别急，我明白我们都是程序猿，不是技术文枪手!但这就是你没想明白的地方。为一个软件写Readme着实非常有必要性。在给你的软件写点什么东西前，你根本不知道你要编写什么样的代码。在人人喊打的瀑布型设计和人见人爱的敏捷开发之间，我们似乎漏了点什么。别误会，瀑布型设计代价太大。它能把一个细致入微的庞大系统变成一个细致入微却全盘错误的系统。当初砍掉它是个正确的做法，但做法却矫枉过正。如今我们的项目里只有短小、糟糕的文档甚至完全不见踪影。你能想象有些项目完全没有Readme吗!
简直难以接受!在成堆的技术规格和完全没规格之间，必然会有个平衡点。那个平衡点就是朴素简明的Readme。
将Readme驱动开发(下文简称RDD)区别于文档驱动开发(下文简称DDD)十分重要。RDD可以理解成DDD的一个有限版本或子集。通过将你的设计文档精简成一个旨在介绍软件的单个文件，RDD能帮助你免于重蹈DDD而出现的瀑布型开发过程中出现冗长而过分细致的规格。同时，它能帮助你保持库的精简和模块化。这样一个简单的方法能帮助您免去繁琐的流程保证项目朝着正确的方向前进。
通过写第一个Readme，您能受益于以下这些显著的优势:
最为重要的一点是，您给于了自己一次重新审视项目，又无需每次为了改变主意而去修改代码而花去开销的机会，例如整体应该如何组织、公用API里到底应该包含哪些东西。还记得您第一次写自动化测试代码，意识到揪出全部的错误从而防止那些问题悄悄跑进代码里去吗?在项目真正编码前写一个Reame的感觉是如出一辙的。
为了明确应该实现什么而去写Readme会产生一些副产品，您会得到一份写的非常棒的文档。当您在项目伊始，也就是兴奋度和动机处于最高的阶段，写一个文档会十分容易。事后再补Readme将是一种绝对的障碍，并且您会发现遗漏了许多重要的细节。
如果您与一群开发者一起协同工作，将会发现会从Readme收益颇多。如果其他成员在您尚未完成项目前便可以读到这份Readme，他们将大可放心的在将与您项目有交互的代码上开始工作。如果没有预先定义好的接口，团队只能顺序地编码或者面临重新实现大量代码的窘境。
基于白纸黑字的讨论将会容易的多，而在一个没有任何成文内容的讨论话题上，事情往往会演变成争论不休。把建议的解决方案写下来这样一个简单的行动，代表了一个具体的想法，从而能被讨论，迭代发展下去。
把给您项目写Readme的过程当作一种真正的创造活动吧，这是您充满闪光的想法应该被表达的地方，这份文件的本意应当是阐述您的创造力和表现力。Readme应当是您代码中最为重要的一个文档，适当的做法就是首先写Readme。
__END__