设计文档的长度 设计文档需要足够丰富凝练，以便忙碌的人可以真正阅读 。一个比较大的项目最佳长度是 10-20 页 。如果你的文档太长，最好将问题分解成多个可控的子问题 。值得一提的是，写一份 1-3 页的“迷你设计文档”是绝对可行的 。这对于敏捷项目中的增量改进或子任务特别有帮助——你仍然可以像处理一个长文档那样处理所有步骤，只需要保持简洁并且聚焦于一个有限的问题集 。
什么时候不要写设计文档 写设计文档是有开销的 。是否编写设计文档的决定归根结底于核心权衡，即围绕设计、文档、高级评审等方面达成共识的好处是否超过创建文档的额外工作负担 。这个决策的核心在于设计问题的核心是否模棱两可——这取决于问题的复杂度或者方案的复杂度，或者兼而有之 。如果设计问题的核心并不模糊，那么就几乎没有价值去编写一份文档 。
如果设计文档实际上是实现手册，那么这就是一个设计文档不必要的明确指标 。如果一个文档基本上在说“我们是如何实现的”，而不涉及权衡、替代方案和决策解释（或者这个方案是如此明显以至于不需要权衡），那么直接编写实际程序可能是个更好的主意 。
最后，创建和审核一个设计文档的开销可能与创建原型和快速迭代不兼容 。然而，大部分软件项目确实存在一些实际已知的问题 。遵循敏捷开发方法并不是不花时间去解决实际已知问题的借口 。另外，原型构建本身可能就是创建设计文档的一部分 。“我试过了，它起作用”是选择一个设计的最佳论据之一 。
设计文档的生命周期 设计文档的生命周期的几个步骤是：
- 创建并快速迭代审核（可能有多轮）实现和迭代维护和学习
当文档被分享给最了解问题领域的同事（通常属于同一个团队）时，这个阶段会快速演变到快速迭代期，通过他们将问题搞清楚以及提供建议，让文档进入第一个相对稳定的版本 。
虽然你肯定会发现工程师甚至团队喜欢版本控制和代码评审工具来创建文档，但是谷歌的大部分设计文档是用 Google Docs 创建的，并且大量使用了它的协作功能 。
评审 在评审阶段，设计文档会被分享到除初始作者和密切协作者之外的更广泛读者 。评审可以带来许多价值，但它们也是危险的开销陷阱，所以要明智地处理评审 。
评审有多种形式：比较轻量的方式是将文档发送给（比较广泛的）团队列表中，让人们都有机会看一看 。讨论主要发生在文档的评论环节 。比较重的评审，是正式的设计评审会议，在会议上，作者将文档（通常是一个专门的演示文稿）展示给级别较高的工程师 。谷歌的许多团队都会为此定期召开会议，工程师可以报名参与评审 。当然，等待这些会议的召开会明显减慢开发进度 。工程师可以通过直接寻求关键性反馈来缓解这种情况，而不是阻碍更广泛的评审流程 。
猜你喜欢
- 玛雅人的五大预言是真的吗 玛雅人的五大预言分别是什么
- 效果最好的4种投放方式 微信公众号投放广告操作模式
- 文天祥是哪个朝代的爱国英雄 文天祥是民族英雄吗
- 以前七夕节的由来与习俗介绍 七夕节有什么传统的风俗
- 吴用为什么被称为智多星 水浒传中智多星是谁的绰号
- 越陈越好-普洱茶的误区
- 华表柱多高多重的样子 天安城门旁边的柱子叫什么
- 怎样查对方的手机位置 女朋友老是登陆我的id查自己的位置
- 明朝末代皇帝崇祯的结局 明朝最后一位皇帝是谁
- 蒯通见韩信是什么意思 韩信如果听了蒯通的话会怎么样