可工作的软件胜过面面俱到的文档

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档,来对系统及其设计决策的依据进行描述。

然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言,会造成重大的误导。

对于团队来说,编写并维护一份系统原理和结构方面的文档将总是一个好主意,但是那份文档应该是短小的(short)并且主题突出的(salient)。“短小的”意思是说,最多有一二十页。“主题突出的”意思是说,应该仅论述系统的高层结构和概括的设计原理。

如果全部拥有的仅仅是一份简短的系统原理和结构方面的文档,那么如何来培训新的团队成员,使他们能够从事与系统相关的工作呢?我们会非常密切地和他们在一起工作。我们紧挨着他们坐下来帮助他们,把我们的知识传授给他们。我们通过近距离的培训和交互使他们成为团队的一部分。

在 给新的团队成员传授知识方面,最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的,但是代码 是惟一没有二义性的信息源。在团队成员的头脑中,保存着时常变化的系统的脉络图(road map)。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。

许多团队因为注重文档而非软件,导致进度拖延。这常常是一个致命的缺陷。有一个叫做“Martin文档第一定律(Martin’s first law of document)”的简单规则可以预防该缺陷的发生:

直到迫切需要并且意义重大时,才来编制文档。

摘自:Robert C. Martin《敏捷软件开发:原则、模式与实践》