前言
架构设计与编码，是为了解决问题，是一套解决方案。当我们在设计架构和代码开发的时候，有一份相对应的设计文档，可以有效且快速的让团队更好的理解在解决的问题，以及方案的设计思路。
为什么要写设计文档
- 要解决的问题是什么需要用文档先介绍清楚
- 有些问题使用一份设计文档描述思路已经足够
- 解决方案的选择（decision）是权衡的结果，我们不仅需要了解结果，也需要知道结果产生的原因，即权衡的过程。只有记录下权衡的过程，在后续偿还技术债的时候，才可以更方便的理解产生的原因或初衷，并有更充分的执行架构演进的依据
- 让团队成员对问题和设计有一个共识
设计文档核心内容
基于以上原因，我们也可以推论出，设计文档所需要具备的核心内容：
- 问题的上下文。一个问题需要解决，自然需要关于该问题的上下文内容。
- 想要达成的目标是什么
- 哪些不是我们的目标
如果在讨论与设计过程中，发现一些可能会对设计带来干扰，但是明确不是当前要解决的目标，需要记录下来，以便团队对此形成共识 - 权衡的过程
- 为什么选择某个方案
- 为什么不选择某个方案
如果对于某一个方案，有十分明确的不使用的原因，尤其是行业有充分的应用经验而设计的时候考虑不使用的时候，需要将其记录下来，作为权衡的参考，以避免后续团队演进设计的时候，朝着原先不选择的方案前进。 - 当前的一个或多个方案有什么条件限制或成本考虑
- 收益是如何的，创造的价值是什么
什么时候写设计文档
在着手实现之前，先完成设计文档的撰写与迭代。
不要试图等到将功能实现之后在补充文档。开发者喜欢写代码甚于写文档。对于开发者来说，在文档中描述某种架构实现方案，不如实现一个demo来演示该方案。当开始写demo之后，很可能就会开始将demo做修修补补，最后完成一份可上线代码。当代码完成之后，除非有某种强制推力要求自己必须完成，或是为了向多个团队或个人介绍自己的方案而减少
在实现之前，完成设计文档的撰写与迭代，可以持续的思考自己的设计的缺陷，并记录下来
设计文档的基本写作步骤：
打草稿 -> 重写 -> 重写 -> 重写 -> 重写 -> …
- 需求持续在变
- 有新的设计想法或方案
- 有新的condition或constraint出现，需要调整设计
写文档是一件有趣的事情
写文档，犹如在将学习理解掌握的事情，再向其他人介绍与论述，以寻求与他人的共鸣。我们在白板前讨论的问题，在讨论完毕之后就会被擦除；我们编写的代码，会因为各种需求的变化而被调整（感谢svn让我们可以回顾第一行代码）。而文档，在未来的某一天，仍旧将有人会来翻阅，如同著书立说，言论可能会过时，但是却是在当下时代的最佳产物。