作者：chen_h
微信号 & QQ：862251340
微信公众号：coderpai
在这篇2010年的文章里，作者鼓励程序员们在写代码前先写 README，先把思路理清楚。代码写再好但没需求，也是白搭。最近作者创办的公司以$75亿卖给了微软，这就是 GitHub。
我现在听到很多关于TDD和BDD以及极限编程和SCRUM的讨论，以及用于开发更好软件的会议和各种方法和技术，但除非我们正在构建的软件满足那些需要的软件，否则它们都无关紧要。 让我换一种方式。 错误的实现完美规范是毫无价值的。 按照同样的原则，一个没有文档的精美图书馆也几乎毫无价值。 如果你的软件解决了错误的问题，或者没有人能弄清楚如何使用它，那就会发生一些非常糟糕的事情。
那么我们如何解决这个问题呢？ 它比你想象的要容易，而且重要的是保证它自己的段落。
首先，请写下你的 Readme 文件。
第一。在编写任何代码或测试或行为或故事或任何内容之前。我知道，我们是程序员，而不是技术作家！但那就是你错了。编写 Readme 文件对编写优秀的软件至关重要。在你写完软件之前，你不知道你要编写什么。在对瀑布设计的强烈反对和对敏捷开发的最高接受之间，有些东西丢失了。不要误会我的意思，瀑布设计太过分了。以微小细节指定的巨大系统最终成为以微小细节指定的错误系统。但取而代之的是在另一个方向上走得太远了。现在我们的项目包含简短，写得不好或完全缺失的 Readme 文档。有些项目甚至没有 Readme 文件！
这是不可接受的。在大量的技术规范之间必须有一些中间立场，但这个立场有吗？实际上有。中间立场是简陋的 Readme 文件。
将 Readme 文件驱动开发与文档驱动开发区分开来非常重要。 RDD可以被视为DDD的子集或限制版本。通过将您的设计文档限制为单个文件，该文件旨在作为您的软件简介阅读，RDD通过惩罚您冗长或过度精确的规范来保护您免受DDD变成瀑布综合症的影响。同时，它奖励您保持库小和模块化。这些简单的增援措施大大有助于在没有大量流程的情况下将项目推向正确的方向，以确保您做正确的事情。
首先编写 Readme 文件，您将获得一些非常显着的优势：
-
最重要的是，你给自己一个机会思考整个项目，而不必每次改变你的想法时都要改变代码，因为你应该如何组织某些事情或者应该包含在Public API中。还记得当你第一次开始编写自动代码测试时的感觉，并意识到你遇到了各种错误，否则会陷入你的代码库吗？如果您在编写实际代码之前为项目编写自述文件，那将是完全相同的感觉。
-
作为编写 Readme 文件的副产品，以便了解您需要实现的内容，您将拥有一个非常好的文档放在您面前。您还会发现，当您的兴奋和动力达到最高时，在项目开始时编写此文档要容易得多。追溯写 Readme 文件是一种绝对的拖累，当你这样做时，你肯定会错过各种重要的细节。
-
如果您与开发团队合作，您可以从 Readme 文件中获得更多的里程数。如果团队中的其他人在您完成项目之前都可以访问此信息，那么他们可以放心地开始处理与您的代码交互的其他项目。如果没有任何定义的接口，您必须以串行方式编写代码，或者重新实现大部分代码。
-
根据写下的内容进行讨论会简单得多。如果没有任何文字，那么很容易无休止地和圈子里谈论一个问题。写下一个提议的解决方案的简单行为意味着每个人都有一个可以争论和重复的具体想法。
考虑将项目 Readme 文件编写为真正的创建行为的过程。 这就是你应该表达所有精彩创意的地方。 本文档应独立存在，以证明您的创造力和表现力。 自述文件应该是代码库中最重要的单个文档; 先写它是正确的事情。
