on
README 驱动开发
我近来听到很多关于 TDD（测试驱动开发）、BDD（行为驱动开发）、极限编程和 SCRUM（敏捷开发）的讨论，还有站立式会议，以及各种开发更好软件的方法和技术。但这些都是无关紧要的，除非我们正在开发的软件能够满足使用者的需求。让我换一种说法，完美地实现错误的规范毫无价值。按照同样的原则，一个精美但没有文档说明的软件库也几乎毫无价值。如果你的软件解决了错误的问题，或者没有人知道如何使用它，那么就会发生一些非常糟糕的事情。
好吧，那么我们如何解决这个问题呢？它比你想象的要简单，而且它的重要性足以保证值得这样做。
首先写出你的 Readme 文档。
是的，首先。比如，在你写代码、测试、行为、故事或任何东西之前。我知道，我知道，我们是程序员，该死的，不是技术作家。但这样想，你就错了。写一个 Readme 对于编写好的软件来说是绝对必要的，否则你根本不知道你编码干什么，除非你已经写完软件。对瀑布设计的强烈反对和对敏捷开发的热烈推崇之间，我们忽视了大片的中间地带。不要误解我的意思，瀑布设计的确太过分了。每个细节都详细定义的庞大系统最后变成一个错误的系统，我们反对它是正确的。但取而代之的是另一个极端，现在很多项目要么文档太过简短，要么文档质量很差，要么完全没有文档——有些项目甚至连一个 Readme 都没有。
这是不能接受的。在大量的技术规范和完全没有规范之间必须有一些中间地带。事实上，我们有这个中间地带，它就是卑微的 Readme。
把 Readme 驱动开发（RDD）从文档驱动开发（DDD）中区分开来是非常重要的。RDD 可以被认为是 DDD 的子集或受限版本，通过将你的设计文档限制在一个单一的文件中（这个文件的目的是为了介绍你的软件），RDD 避开冗长或过度精细的规范，从而保证你免于 DDD 引发瀑布综合症。与此同时，你的收获是，软件库保持小型和模块化。这些简单的增强方法可以让你的项目朝着正确的方向发展，而不需要花费太多的时间来确保你做正确的事情。
一开始就写下 Readme，你会给自己一些非常重要的优势。
- 最重要的是，你给自己一个机会去思考这个项目。每当你改变想法（代码如何组织，公共 API 中应该包含哪些东西），就不得不改变代码。通过预先思考，可以避免这种浪费。还记得那种感觉吗？你第一次开始编写自动化代码测试的时候，你意识到你发现了各种错误，否则这些错误会潜入代码库。如果你在编写实际代码之前为你的项目撰写 Readme，你也会有同样的感觉。
- 为了知道你想要实现什么，你撰写 Readme，结果就是你将有一个非常好的文档放在你面前。你还会发现，在项目开始时，你的兴奋和动力达到最高点，彼时写下这份文件要容易得多。追溯性地写一个 Readme 绝对令人厌烦，当你这样做的时候，你肯定会错过各种重要的细节。
- 当开发团队一起工作时，可以从 Readme 中获得更多的好处。如果团队中的其他人在你完成这个项目之前就已经获得了项目信息，那么他们就可以自信地在其它项目里开始与你接口相关的工作。如果没有任何定义好的接口，大家就必须以串行的方式编写代码，否则就面临重新实现大部分代码的风险。
- 基于写下来的东西进行讨论要简单得多。如果没有文档记录，那么讨论问题很容易陷入无休无止和循环往复。把提议的解决方案写下来这个简单的动作，意味着每个人都有一个能够被讨论和迭代的具体想法。
考虑为你的项目写一个 Readme 的过程是真正的创造行为，这就是你所有出色的想法应该表达的地方。这份文件应该自成一体，证明你的创造力和表现力。在你的代码库中，Readme 应该是最重要的文档，正确的做法就是首先把它写出来。