都说 Developers 不爱写文档，其实不然，能创造出有价值的东西肯定是让人快乐的。不论写的是代码，还是文档，只要能确切地给人帮助，那一定是很振奋的，特别是能直接得到积极反馈的时候。最近越发觉得文档和代码一样重要，于是读了《活文档：与代码共同演进》这本书。读完后还真是挺佩服作者的，能把写文档弄得如此细致严谨、「正儿八经」。看起来没多大的事儿，写成书倒是厚厚一叠。

先说 BDD，首先作者提的许多建议都是很有价值的，不过他推荐的BDD 我持保留意见。不太准确地归纳，BDD 更像是 TDD 的升级版，是一个模版化的 TDD。Agile 项目是由 Product Owner 写出需求文档，然后DEV 把它转化成 Unit Tests。BDD 无非是要直接把需求文档也写到代码里去了。看起来的确很美好，不过这里对人就有要求了，要不就是DEV具备 PO 的理念，要不就需要 PO 直接能写代码。DEV 和 PO 少不了还要常常结对才行。这 … 回看做了这么多年的 TDD，都很难落地，BDD 的难度可想而知了。大多数情况下，「项目三角」约束得死死的，要做一个即使看不到的细节也漂漂亮亮的项目，那是很奢侈的。当然如果「有追求」的话，确实可以尝试尝试。

再说广义的文档概念，对人也仍然是有要求的，准确地说需要对「文字有感觉的人」。愿意去写，还是很难的。和代码不同，因为不能直观地获得反馈，比起在 IDE 的帮助下哐哐敲出代码，用文字不仅要描绘得准确，还要考虑排版格式，美观易读 … 这并不简单。当然写作能力肯定能一步步提高，如果能逐渐让团队里大多数人慢慢做起来，那当然是一个让人幸福的事情。不过，或许只能叫做理想。

回过头来还是开篇说的，文档几乎和代码一样重要，肯定是要写的。简单归纳一下和我的个人体会，方便继续实践，如果能坚持这些理念，我觉得足够「偷懒」的人，自然就能玩出花来了：

• 情感上我们应该「爱写」，但是我们的目标是「不写」。
• 能不写就一定不要写！绝大多数信息都不需要被写下来！用口头或者简单笔记交流的东西，不需要特别用文档方式记录下来。
• 文档太多一定是项目出问题了！
• 储存文档的最佳位置是被记录的事物本身。优化设计和代码，用编程的「通用语言」或者优质的测试用例来代替传统文档。目标仍然是不写「文档」。
• 只有稳定的「知识」需要用传统文档的方式记录下来。
• 文档要简洁，尽量不费力气，够用就好。
• 特别注意不能只是记录结果，还需要记录做出选择的条件。
• 把编写文档的语言，也当成是程序开发的语言。用编写代码的要求来重构文档。
• 代码是用来运行的，文档是给人读的。不被使用的文档不需要存留。