写出一份“有理有据使人信服”的Android项目设计文档，这个技能也很重要！

周末？不存在的。

在大厂，写得一手好文档是一个非常吃香的技能。这可不只是一个锦上添花的东西，而是很多工程师晋升，打造自己话语权的武器。

我这两年在组内的深刻体会就是，大部分厉害的高级工程师（不包括那些纯混日子靠资历晋升的人），写文档的能力一点也不含糊，很能抓住上级和项目的G点。

可能有人会觉得，我技术牛逼就行了，为啥还要提高写文档的能力，有这功夫我还不如多看看源码分析？

这是一些初级或者刚入门的工程师的普遍的困惑。

这是因为大部分刚刚入行的朋友有一个很深的误区，就是他们以为做软件工程是一个和计算机打交道的工作，其实不然。软件工程不只是和代码打交道，更重要的是和人打交道，是一份社会性质很强的工作。

在大部分公司里面，尤其是大厂，牵涉到的人，组，都是非常非常多的。在小厂，人与人之间交流意见和设计可以口口相传，心领神会，但是一旦人开始多了，就只能靠文档了。除非你可以厉害到一个人把所有代码撸完，不然还是最好老老实实的夯实自己写文档的能力。

如果你有写技术博客的习惯，那么恭喜你，相信你已经对如何抓住文档受众的技巧有所了解了。这对你在大厂生存有很大的帮助。如果没有也不要伤心，这篇文章就是为你精心设计的。

在这篇文章里，我会大致的把一份安卓的项目设计文档的骨架，和一些我工作中实际遇到的正反例都列出来，方便大家以后在工作中实践。

设计文档的结结构

一个好的项目设计文档，其实有一定的模板可以参考的，不过不管模板怎么变，大致都需要有以下几个大框架

1. 项目背景
2. 项目术语
3. 技术挑战
4. 完成要求 （App性能要求 (可选)，App Size 要求 (可选)）
5. 现有架构(可选）
6. 建议架构（引入的第三方框架/SDK的简介 (可选)）
7. 开发时间线
8. 其他可选架构(可选)
9. 参考文献

咱先从项目背景开始聊。

项目背景

如果大家面试次数够多，应该会有听过一个叫STAR原则的东西，就是介绍自己项目的时候要遵循Situation(背景)->Target(目标)->Action(行动/做法)->Result(结果)这样的顺序，尽量做到简洁。

同样的，项目背景的介绍就是对应了这个STAR原则的S，也可以说是项目的动机，为什么要做这个项目。

这个背景和动机可以是一个产品产生的动机。

比如说抖鹰的产品经理发现竞品快脚发提供了一个新的视频滤镜，而且这个滤镜在竞品快脚 中迅速攀升到用户热度的第一位了，基于我们在产品的数据分析中blalala。。。于是我们也要做这个滤镜。这就是一个简洁明了的项目背景。

当然这个背景也可以是一个纯技术方面的问题，比如架构的升级等等，当然如果是架构的升级，那需要在背景里面简单的介绍现有架构的大概的一些局限性(我们下文会提到)。

本人阅读过的一些经典反例就是，背景介绍的第一句话上来就开始直接飙产品/公司内部的一些黑话，比如某个sqlite 的 database的某一个col有问题啊，或者是公司内部的一个SDK的限制等等。

这些都是技术细节，不是项目大背景。提前把这些细节说出来是没法在第一段就抓住读者的眼球的，这会让读者失去仔细观看全文的热情，导致最后你的设计文档可能收不到任何有意义的反馈。

项目术语

这一部分就更重要了。项目术语这个部分必须要尽可能的把设计中涉及到的：

1. 新引用的SDK/框架
2. 项目之前没用过的语言
3. 项目/公司内部工具,服务
4. 产品本身的组件Component.

都过一遍࿰