自述驱动开发

这些天，我听到很多关于TDD和BDD以及Extreme Programming和SCRUM的话题，并有会议，各种方法和技术来开发更好的软件，但是这些都是无关紧要的，除非我们所开发的软件能够满足那些需要正在使用它。让我换种说法。错误规范的完美实现是毫无价值的。出于同样的原则，一个没有文档的精美库也几乎毫无价值。如果您的软件解决了错误的问题，或者没有人能弄清楚如何使用它，则可能发生了非常糟糕的事情。

精细。那么我们如何解决这个问题呢？它比您想像的要容易，而且非常重要，足以保证它自己的段落。

第一。与之类似，在编写任何代码或测试，行为，故事或任何东西之前。我知道，我知道，我们是程序员，该死，不是技术作家！但这就是你错的地方。编写自述文件对于编写优秀的软件绝对至关重要。在您撰写有关软件的文章之前，您不知道要编写什么内容。在对瀑布设计的强烈反对与对敏捷开发的最高认可之间，有些东西丢失了。不要误会我的意思，瀑布设计将事情推得太远了。细部指定的庞大系统最终成为细部指定的WRONG系统。我们将其击倒是正确的。但是，它所取代的东西在另一个方向上太过分了。现在，我们的项目中的文档简短，写得不好或完全缺失。有些项目甚至没有自述文件！

这是不可接受的。在技​​术规格的范围之间必须有一些中间立场，而根本没有规格。实际上，确实存在。中间立场是谦虚的自述文件。

将自述驱动开发与文档驱动开发区分开来很重要。 RDD可被视为DDD的子集或受限版本。通过将您的设计文档限制为一个文件，该文件应作为您的软件介绍来阅读，因此RDD会因惩罚冗长或过于精确的规范而使您免受DDD折衷的瀑布综合症的伤害。同时，它会因使库保持小型化和模块化而受到奖励。这些简单的增强功能可以朝着正确的方向推动您的项目，而无需花费大量的过程来确保您做正确的事情。

最重要的是，您给自己一个机会来思考项目，而不必每次更改主意如何组织某些内容或将什么包含在Public API中时都必须更改代码。还记得第一次开始编写自动化代码测试并意识到捕获了各种本可潜入代码库的错误时的感觉吗？如果您在编写实际代码之前为项目编写了自述文件，便会感到完全一样。

作为编写自述文件以了解需要实现的内容的副产品，您面前将拥有一个非常不错的文档。您还会发现，当您的兴奋和动力达到最高水平时，在项目开始时编写此文档会容易得多。追溯性地编写自述文件绝对是一件麻烦事，并且您一定会错过所有重要的细节。

如果您与开发人员团队合作，那么自述文件将为您带来更多的收益。如果团队中的其他所有人都可以在完成项目之前访问此信息，那么他们可以放心地开始其他与您的代码交互的项目。如果没有任何已定义的接口，则必须以串行方式进行代码或重新实现大部分代码。

根据写下来的内容进行讨论要容易得多。如果没有在文本中输入任何内容，则可以无休止地无休止地谈论问题。写下提议的解决方案的简单动作意味着每个人都有一个可以争论和反复讨论的具体想法。

将为您的项目编写自述文件的过程视为创建的真实行为。在这里，您应该表达所有出色的想法。该文档应独立作为您的创造力和表现力的证明。自述文件应该是您的代码库中最重要的文档。首先编写它是正确的事情。