谷歌软件工程文化的主要元素之一就是通过设计文档定义软件设计 。在开始项目编码工作之前，软件系统或应用程序的作者会创建这些相对非正式的文档 。设计文档记录了高级实现策略和关键设计决策，并且重点记录了这些决策之间的权衡考虑 。
作为软件工程师，我们的工作本质上不是生产代码，而是解决问题 。非结构化文本，类似设计文档的形式，也许是在项目早期解决问题比较好的工具，因为它易于理解、更简洁，且以比代码更高的层次来沟通问题和方案 。
除软件设计的原始文档外，设计文档还实现了软件开发周期中的如下功能：
在早期发现设计问题，而那时变更的成本还比较小在组织内围绕设计达成共识确保考虑到交叉领域的问题将高级工程师的知识扩展到组织中围绕设计决策形成组织记忆的基础在软件设计师的技术组合中充当总结工具设计文档的结构 设计文档是非正式文档，因此它们的内容不会遵循严格的准则 。一个首要原则是，针对具体项目可以用任何最合理的形式编写 。
话虽如此，形成的特定结构必定有其价值所在 。
上下文和范围 这一部分会粗略地向读者介绍新系统是如何构建的以及实际情况如何 。这不是需求文档 。请保持简洁！我们的目标是直接让读者了解最新情况，但先前的一些情况可以被推测或者能链接到详细信息 。这个部分应该完全聚焦于客观背景事实 。
目标和 non-goals 这一部分会列举出系统目标是什么，但有时候更重要的是，列出系统的 non-goals 。注意，non-goals 并不是像“系统不应该崩溃”这样的负面目标，而是那些本可以合理地成为目标但却明确地选择不作为目标的东西 。一个很好的例子是“ACID 准则”；当设计数据库时，你肯定想知道这是一个目标还是一个非目标 。而如果这是一个 non-goals，如果它不会阻碍目标的实现，那你仍然可以选择一个提供它的解决方案 。
实际设计 这一部分应该从概述开始，然后扩展至详情 。
设计文档适合写你在设计软件时所做的权衡 。把重点放在这些权衡上，来产出具有长期价值的文档 。换句话说，给定上下文（事实）、目标和 non-goals（需求），设计文档可以提供建议方案并展示为什么某个特定方案最能满足那些目标 。
在比较正式的媒介上，编写文档的目的是提供灵活性，以适当的方式展示手头的问题 。因此，对于如何真正地描述设计并没有明确的指南 。
尽管如此，对于大部分设计文档来说，一些最佳实践和重复话题都很有意义：
系统语境图 在许多文档中，系统语境图都非常有用 。这样一张图将系统作为更大技术环境的一部分展示，允许读者结合他们已经熟悉的环境进行理解 。
推荐阅读
- 玛雅人的五大预言是真的吗 玛雅人的五大预言分别是什么
- 效果最好的4种投放方式 微信公众号投放广告操作模式
- 文天祥是哪个朝代的爱国英雄 文天祥是民族英雄吗
- 以前七夕节的由来与习俗介绍 七夕节有什么传统的风俗
- 吴用为什么被称为智多星 水浒传中智多星是谁的绰号
- 越陈越好-普洱茶的误区
- 华表柱多高多重的样子 天安城门旁边的柱子叫什么
- 怎样查对方的手机位置 女朋友老是登陆我的id查自己的位置
- 明朝末代皇帝崇祯的结局 明朝最后一位皇帝是谁
- 蒯通见韩信是什么意思 韩信如果听了蒯通的话会怎么样