Readme Driven Development
名词解释
RDD ： Readme Driven Development
TDD ： Test Driven Development
BDD ： Behavior-Driven Development
XP ： Extreme Programming
SCRUM : 迭代式增量软件开发过程
翻译
最近我听到很多关于TDD、BDD、XP、SCRUM、站会以及开发更好软件的各种方法和技术的讨论，但这些都是无关紧要的，除非我们所构建的软件能够满足用户的需求。
让我换一种说法。
有关错误相关的规范的完美实现是毫无价值的。基于同样的原则，一个精心制作的没有文档的库也几乎毫无价值。如果你的软件解决了错误的问题，或者没有人知道如何使用它，那一定是非常糟糕的事情。
那么，我们如何解决这个问题呢？
它比你想象的要简单，而且它足够重要，可以用一段话来说明。
Write your Readme first.
首先，README应在你写任何代码、测试、行为、故事或任何其他东西之前。我知道，我知道，该死的，我们是程序员，不是技术作家！但这就是你错的地方。编写README对于编写好的软件是绝对必要的。除非你已经编写完软件，否则你甚至不知道要编写什么代码。
在对瀑布设计的强烈抵制和对敏捷开发的高度接受之间，有些东西遗失了。不要误解我的意思，瀑布式设计太过分了。它以小细节指导庞大的系统最终会成为在小细节中指导出错误的系统。我们推翻它是对的。但取代它的另一个方向又太远了。
现在我们有一些项目的文档很短，写得很糟糕，或者完全没有文档。有些项目甚至没有README！这是不可接受的！在大量的技术规范和根本没有规范之间必须有一个中间地带。事实上，这个中间地带就是谦逊的README。
区分RDD和DDD是很重要的。RDD可以被认为是DDD的子集或有限版本。将你的设计文档限制在一个单独的文件中，作为你的软件的介绍来阅读，RDD通过惩罚冗长或过于精确的规范来避免DDD变成瀑布综合症。与此同时，它还鼓励你保持库的小和模块化。这些简单的增强功能对推动项目朝着正确的方向发展大有帮助，而无需大量的过程来确保你在做正确的事情。
通过先写README，你会给自己带来一些非常明显的优势：
-
最重要的一点，你为自己提供了一个全面思考项目的机会，而不必在每次更改关于应该如何组织某些内容或应该在Public API中包含哪些内容的想法时更改代码。还记得当你第一次开始编写自动代码测试并意识到你捕获了所有可能潜入代码库的错误时那种感觉吗？如果你在编写实际代码之前为项目编写了README，你会有同样的感觉。
-
作为编写README的副产物，为了知道你需要实现什么，你会有一份非常好的文档摆面前。你还会发现，在项目开始时，当你的兴奋和动力达到最高时，编写这份文档要容易得多。追溯编写README绝对是一种累赘，而且你肯定会错过各种重要的细节。
-
如果你和一个开发团队一起工作，你会从你的README中得到更多的好处。如果团队中的每个人都能在你完成项目之前访问这些信息，那么他们就可以自信地开始处理与你的代码交互的其他项目。如果没有任何类型的定义接口，你就必须串行编码或重新实现大量代码。
-
基于写下来的东西进行讨论要简单得多。如果一个问题从来没有付诸文本，人们很容易没完没了地兜圈子进行讨论。写下一个提议的解决方案的简单行为意味着每个人都有一个具体的想法，可以进行讨论和迭代。
把为项目编写README的过程看作是真正的创作行为。你所有的好主意都应该在这里表达出来。这份文件应该是你创造力和表达能力的证明。
README应该是代码库中最重要的文档。先写是正确的做法。
