故事
小猫连续承担责任，让他的内心受到了巨大打击，这在他的职业生涯中是首次。如果对小猫的处境感兴趣，可以了解“幂等事件”和“缓存击穿事件”。
这天组长找小猫来到了一间会议室。
在这么短的时间里发生了这么多事故，我理解这对你来说也很不容易，毕竟你刚接手这个项目。或许项目本身就存在一些问题。现在责任落到你头上，希望你不要泄气……”，组长在一旁继续说道。
小猫看着小鸡点头，感到放心了。心想：“看来组长不会批评我的绩效。”
然而，问题已经出现，系统可能存在其他问题，包括业务、代码或设计方面。请抽出时间进行整理，并准备一份项目文档分析。我们期待您在下次月会上与大家分享系统的现状。
小猫连连点头，心里琢磨“这应该算是变相抓典型吧，罢了罢了，可是，这样的一份文档该怎么写呢”
此时小猫的内心又开始不安起来。
聊聊熟悉新项目
当接手到一个新的系统的时候，大家是如何进行熟悉的呢？其实老猫在上一篇“缓存击穿事件”的文末就问过大家了，不晓得大家还有印象不？
现在我们来谈谈老猫对一个新系统的熟悉过程。希望这些经验对你有所帮助，也欢迎分享你自己的方法。主要步骤如下：
项目熟悉
1.尝试画一下用例图
当接受到一个新的业务系统之后，首先咱们至少需要知道当前这个系统是干什么的，所以有时候就需要抽时间找到相关的产品经理了解一下业务，此时产品经理可能会和你聊一下现有的业务现状和背景，但是有可能也会直接丢给你一份V0-Vn版本的产品需求方案，并告诉你他没空。如果是后者记住千万得忍住，不要用显示器砸产品的脸，因为你们的合作尚未开始……开个玩笑，言归正传。
我们先了解一下什么是用例图。
用例图简析
用例是系统中的一个功能单元，可以被描述为执行者与主体之间的一次交互行为。执行者是与系统、子系统或类发生交互作用的外部用户、进程或其他系统的理想化角色。
用途：能够列出系统中的用例和执行者，并显示哪个执行者参与了哪个用例的执行。
针对之前小猫遇到的“下单付款的业务点”，咱们来画个用例图说明一下。如下图：
用例
如上图其实就是一个简单的用例图。我们需要搞清楚的是各种线条的含义。
- a线条表示的是关联即执行者与其参与的用例之间的通信路径。用实线表示。
- b线条表示包含，在基用例上插入附加的行为，并且显式地描述了该插入。
- c线条表示扩展，在基用例上插入附加的行为，基用例并不知道。
- d线条表示用例泛化，一般用例和特殊用例之间地关系，其中特殊用例继承了一般用例的特征并增加了新的特性。
这样我们就可以很清晰地了解当前的业务现状。
2.后端模型梳理
当梳理完当前的系统功能点以及业务形态的时候，我们就可以介入去看一下现有系统的模型了即DB数据库的表。这样我们就能知道当前设计的系统是如何对业务进行抽象的。那么在看相关表的时候，其实我们就可以慢慢地将ER图进行绘制出来了。
沙之丘企业网站程序是一个以asp.net(C#) 4.0 +access进行开发的企业网站源码。主要功能：1、产品、设备、新闻系统2、留言信息直接发邮件到相关部门3、所有链接都以一级目录显示更好的权重4、其他信息扩展，可以增加如：人事招聘，公司介绍，地图，联系我们等5、带有商品和设备的搜索功能6、模板动态化方便扩展模板7、简体繁体选择显示运行环境：windows 2003或者更高windows服务
什么是ER图
E-R图即全称实体-联系图(Entity Relationship Diagram)，它提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
通过其定义其实我们就知道了在ER图里面有三个比较重要的点，分别是实体类，属性，联系。当我们在整理DB表的时候其实对应的就是我们的表、表字段以及对应的表和表之间的关系。
看个例子，下面老猫绘制一下一般商城系统底层的商品逻辑。
ER例子
解释一下每一块图的含义：
- 方块表示一个模型即一个表，当然这个也是ER图中的实体类。
- 椭圆形表示实体类包含的属性。
- 菱形就表示两个类之间的动作行为关系，比如上图中商品上架到货架上。日常中老师给学生上课，那么菱形中可能就是上课。
- 线条上的1和n就更清晰了，就是一对多，多对一，一对一的关系。
上图中其实我们就可以比较清晰地看到，在当前的这个系统中存在三个比较重要的实体概念，分别是商品、商品池、以及货架。从图中我们也可以大概地看到他们之间的关系。
当咱们梳理完ER图之后，其实上述的用例业务图如何在现有系统中的抽象大概就清楚了。
聊到这里，咱们从上帝视角去看一下，我们给当前这个系统赋予了骨架，接下来得让它的开始心脏跳动，血液奔腾起来，让整个系统赋予灵魂。那么接下来，我们就把模型通过流程的方式串起来。
3.核心流程以及状态机流转
咱们直接看一下例子，其实老猫觉得流程图的梳理可能比较简单，但是难的是如何去把控整个流程中的环节。如果在绘制的时候想的比较细致，可能每一步的落库环节都会去记录。这样的话对于业务的专注度就会少一些。如果画粗了，模型的对应关系可能又把控不好。所以这个地方老猫觉得还是比较考验程序员的概括能力以及业务的理解能力的。
流程图
上述图中，老猫简单画了一个流程图，当然流程图中可能会存在纰漏，大家不要太过较真，在此是说明这么一个事情，咱们暂且不谈里面业务流程的准确度。上面流程中我们看到有以下图形内容：
- 起始节点，咱们用圆圈表示，当然可以选择自己喜欢的颜色，没有太多标准。
- 流程进行流转的时候，我们用了相关的箭头线表示，涉及到核心业务操作的时候就是方块。
- 遇到分支节点的时候，咱们用菱形去做路由。
- 遇到一些异步操作的时候，老猫喜欢用虚线去表示。
上述这种流程的表示其实是比较简单的，我们不用去在意系统边界。只管绘制即可。
但是现在的开发体系咱们往往都是微服务化的，那么此时我们可能就要考虑到不同系统之间的交互流程。由此，咱们可能机会引入泳道的概念。见下图。
泳道流程
上述图中我们就可以看到各个系统应用之间的交互，每一个泳道就代表着其中的一个微服务系统。这是老猫日常熟悉业务中真实绘制的一张图，再次强调一下大家要看的是绘图的一些思路，不要太过纠结业务。
那么再细节一点，比如讨论到订单状态的一些流转的时候，此时我们为了更好的把控，会使用一些状态的流转图去梳理。
状态流转
上述主要是阐述整个状态在流程中的流转，当然很多时候状态位比较简单的时候，咱们也可以不用画，可能当状态比较复杂多样的时候才会去考虑到画状态机。
