这些天我听到了很多讨论，关于TDD，BDD，极限编程，Scrum，站立会议和各种为了开发更好的软件的方法论及技术，但它们都是无关紧要的，重要的是我们正在构建的软件能够满足一些人的需求。让我换另一种方式说吧。如果采纳了错误的需求，那就是毫无价值的。根据同样的原理，一座精巧美丽的图书馆如果没有任何书籍也毫无价值。如果您的软件解决了错误的问题或没有人能知道怎么使用，这都是很糟糕的事情。
好的。那么，我们如何解决这个问题？这比你想象的更容易，其实你只需要一段话就可以了。
首先，写一个自述(readme)
第一，正如你在编写任何代码或进行测试或其它任何事情之前。我知道，我知道，我们是程序员，该死的，不是高科技的作家！但是，这你就错了。写简介对于编写一个好的软件是绝对必要的。直到你先写点关于你软件的东西，不然你不知道你在写什么代码。在反对瀑布设计，敏捷开发和验收为王之间，一些东西丢失了。不要误会我的意思，瀑布设计需要太多的东西。庞大的系统最终会在微小的细节中产生的错误而结束。我们的罢工是正确的，取而代之的是偏离正确的方向太远太远，我们只有一些短的，写的不好的，或者完全丢失的文档的项目。有些项目甚至没有一个自述！
这是不能接受的。在必须有规格书和没有规格书之间肯定有一个界限。而事实上是这个界限就是不起眼的自述。
正确地区分自述文档(RDD)驱动和文档驱动(DDD)是非常重要的。 RDD可以考虑被认为是DDD的一个子集或有限的DDD版本。通过将你的设计文档变成一个简短的文件，就像是介绍你软件的简介一样，RDD通过去除你冗长或过于精准的规范，让你从DDD的瀑布综合症中保持安全。与此同时，它使你保持简单，模块化。这些简单的功能的叠加，推动你在正确的方向上前行，无需大量工作以确保你做正确的事情。
通过你的自述，你会得到一些非常显著的优势：
1 最重要的是，你应该给自己一个机会来思考，通过无需每次改变代码的来进行这个项目，你写g步关于业务应当如何组织或者什么应该包括在公共API中的想法。还记得当你第一次开始编写自动化代码测试，并且意识到你会抓住那些可能会悄悄进入到你的代码的错误时的感觉吗？这时你将会拥有的完全一样的感觉，如果，在你写的实际代码之前，写下一份自述文件。
2. 作为一个为了让你知道需要实现什么功能而写的Readme，其实会变成一份非常漂亮的文档摆在你面前。如果你在项目开始时写，就不会费什么力，它在你兴奋和激动时写起来更容易。否则它就是一个绝对的阻力，当你这想起来的时候，你一定会错过各种重要的细节。
3. 如果你正在跟团队一起开发，你可以从你的自述文件获得获得更多额外的东西。在你完成这些项目之前，团队的其他人能够访问这些信息，那么他们就可以放心地开始其他方面的工作，而不需要等你 接口好了再进行，他们只需要你自述里定义的一个抽象接口。
4. 有根据写下来的东西进行讨论是一个简单得多的事情。否则很容易滔滔不绝，并为了一个问题兜圈子，如果没有什么是付诸文字。写下一个提议的解决方案是最简单的, 意味着每个人都拥有一个具体的想法，可以争论，可以迭代。
考虑为您的自述文件写在真正动手之前。这里是你展现杰出的想法的地方。此文件应作为证明你创造力和表现力的基石。自述应该是在你的代码库中最重要的文件; 首先写好它是你要做的最正确，最恰当的事情。
