趁晚上有点时间，闲聊几句。
公司很多业务，随之而来的就是很多项目；每个项目都有自己业务流程，代码，如果有项目需要变动人员调整，比如小明本来是A项目组的开发人员，但现在要去项目B组
开发一段时间项目了，那么作为技术人员该如何快速把握B组业务，我们现在很多人做法是，1，不停（时不时）咨询该项目的产品人员询问该项目业务流程，2，从头到尾看B项目的代码结构（现实是很多项目都不是全新开发，更多是的二次升级开发，或从现有框架上搭建项目环境。个人观点从以下两个方面入手可以快速把握新项目的过程。
非技术方面：
1。询问该项目产品业务关键点，以及业务大致流程，做到胸中有图（业务轮廓图）
技术方面： 任何业务有个性同时也有共性，那么我们可以从业务共性入手来降低理解业务的难度。
1。模型（跟业务紧密联系的对象，如：订单，用户，账户对象等）从模型入手了解业务核心参与者，在模型中应该搜索聚合跟对象（比如，用户，顺着用户找下 去，就可以发现与用户关联的对象，从也就明白了用户与之关联的对象间的关系）
2。规则（规则其实也是一个模型，但这个模式系统全局的，是其他模型的执行标准，比如用户购买商品，如何收取佣金，那么这个应该是个规则了，在系统中一 般表现为配置，但也可以是一个核心算法）
3。场景上下文（时间阶段，事件性质，如：转账，下单，比如 我做一个监控系统，那么分布式服务端（NoSQL）监控是一个场景，监控用户访问轨迹又是一个场 景，不同的场景就觉得了使用什么样的规则，场景中一个重要元素是时间，如8~20点是用户访问高峰阶段，一个月月底应该分库了就是场景，场景是使用规则 的潜规则，即场景觉得规则的使用。）
4。事件（简单说事件是一个具体的动作，即做什么。元素：事件的发起者，事件执行环境，事件的协作者，如用户转账，用户就是事件发起者，那么转账需要什 么呢？账户，账户就是参与者）
5。状态（状态可以说在业务某些过程中能够决定是否继续执行事件的决定性因素，如果用户购买商品时，商品不足，那么商品不足其实是状态，这个状态不能满 足要求那用户购买商品这个行为（事件）应该终止的事件阶段性结果，事件完成时的结果，事件结果保存到媒介，如：SQL，NOSQL）
。。。
额，不早了，暂时到此。