如何讲明白一个系统设计

如何讲明白一个系统设计

二宝真好记

粗懂技术，装懂艺术

内容审核中

内容将在审核通过后自动发布

把一个系统说明白并不是一件容易的事儿。有很多工程师宁愿写代码也不愿意写文档。有些工程师在一个系统上工作超过1年了，却依然不能给一个新人一次性讲明白。
不得不说，把系统讲明白是一种能力。

心态：观众视角

永远把观众想象成这样的人：有点技术基础，对业务场景一知半解，对系统实现完全无感，智商方面比自己低一二个层次。
要有秒变观众的能力。切换视角之后，自己认为讲解是否清晰明了？ 如果还不够，改。

逻辑：分而治之的套路

对于每一个系统，我们应该采用这样的原则去叙述

1. My name is A， a brief introduction
2. where am I (the overall picture including me)
3. what’s my function ( connections and interfaces of mine )
4. how did I looks like ( how many parts do I have; what’s the connections between them; the flow chart of main functions.
5. for each parts of A, goto 1
   
   绝大多数系统，这种分而治之的循环走一重就OK了，少数复杂的系统走两重。极少遇到三重循环的。

次序：先做脑图后写文档

• 做任何的文档必有目录。
• 目录是一篇文章的骨架。
• 骨架不清晰，一定是个失败产品。
• 必须先形成骨架，后填充血肉。
• 建议先在脑图上勾画出你的目录树结构，至少做两级。
• 仔细斟酌目录树上父子是否应该为父子，兄弟是否应该为兄弟。
  
  打磨目录树的过程很费脑细胞，但这非常值得。否则把问题往后面拖，后面的成本更高。

一些杂项原则

• 自顶向下，自底向上都好，但一份设计只用一种原则。
• 不需要混淆设计层和代码层。类图属于代码层，不要拿到设计层面。
• 不要电路图，网状关系，复杂的图叫做电路图。元件多，线路复杂，N多交叉。
• 一定要用标题1，2，3的格式。一定要能自动形成目录。
• 最好只用最简单，最标准的框图和流程图。这两种图不能描述清楚的设计，我没见过。
• 多用列表，表格，图表。
• 多举例。

完整的设计

上面讲的注意事项，不过是详细设计部分。一个完整的设计文档应该包含以下部分。
每一部分的进一步细分，以后再说。

1. 概述
2. 设计思想
3. 详细设计
4. 测试，
5. 运维
6. 系统不足和升级方向