开发者真的非常讨厌花时间写东西，除非写的是代码。然而他们还对这种厌恶振振有词：
如果不是代码，它就无法通过编译，也无法确定它是不是有意义。
如果不是代码，它就无法执行，所以可能永远无法用于完成任何事情。
如果不是代码，也就无法对它进行测试，因此也无法证明它的真实与正确。
敏捷宣言中甚至都不再强调文档：可以工作的软件胜过面面俱到的文档。
那文档就一无是处吗？我想你知道答案。
为什么要写下来
很多时候，项目中的些许文档会起到很大的作用。但是要得到那些好处，开发者必须停下手中的代 码，抽点时间把事情写下来。我来举一些例子，我想他们会发现文档物有所值。
记下因何而做的决定
如果项目不止持续几个月，总有这样的时候，所做的决定会改变开发过程。可能是决定使用（或明 确地避免使用）某个特定的工具、框架或平台；可能是决定以某种方式编写测试，或是在某些情况下根 本不编写测试；可能是决定丢掉惯常的实践方式，并且以完全不同的方式做事。这些决定将会出现，而 且往往会持续下去。
在做下决定很久之后的某一天，团队里的某个人（通常是新加进来的，他们很烦人，是不是？）会 问“我们为什么这么做？”。他们会得到什么样的答案呢？
如果团队里有一个人或几个人记性不错，而且这个项目他们也跟得足够久了，新的团队成员或许能 得知真实原因。但是大部分情况下，恐怕答案是“因为我们总是这么做的”。谁都不想听到 这样的答案。
请记住，如果碰到这样的答案，可以有所选择。你可以按照往常做事的方式继续做下去，因为你已 麻木，或是因为这样做更为安全，你已经不记得开始这样做的原因了。作为选择，你可以作出改变，希 望你考虑了所有可能的影响。究竟会出什么问题呢？哦，后来发现问题多的是。例如：
你可能走了一条已经被探索过而且被否定了的路，浪费宝贵的项目时间和精力。
你的修改可能与客户要求的系统工作方式相冲突，让客户非常懊恼。
本来有所缓和的合规审查可能因为你的做事方式而破坏，并使你和/或你的客户遇到法律上的麻烦。
只需要花点时间把事情写下来，这些后果都可以避免。当你的团队做了会改变你工作方式的决定时 ，把当时的日期以及决策背后的逻辑考虑写下来。以后，当有人问起“为什么那样做”或 “为什么使用那个工具”时，你就可以自信满满地回答了。
为将恼人的过程自动化做好准备
开发者经常会发现他们想将一些过程自动化。这些过程经常重复，而且会浪费宝贵的开发时间。然 而，我时常碰到一些执行不那么频繁的手工过程（可能几个月一次），这些过程会涉及一系列步骤，必 须按照特定的顺序完成。如果没人愿意费点力气把这个过程写下来，那就有很大的机会出现执行错误的 情况，或者是执行中漏掉了某些步骤，浪费的时间甚至更多。此外，如果不先把这些步骤写下来，我们 也就没有切实可行的方式将这个过程自动化。
如果你发现自己正在执行的任务有多个步骤，而且这个任务有很大的机会要再次执行，请把这些步 骤写下来。当再有人必须手工执行该过程时，能够节省时间，可能有一天你终于感到非常气馁，于是你 将这个过程自动化了，而今天的行动也为那一天做好了准备。