如题，由于之前部门工作关系，经常需要快速进入一个项目或重构或问题攻关(有时候是公关。。。)，在此总结一下自己每次进入项目的方法和经验。

进入新项目的道与术

道

进入一个新的项目的时候，首要搞清楚自己面对的问题是什么(但是这里往往很难，有可能业务部门都很难说清楚自己问题是什么)，其次要搞清楚自己在项目中主要和哪些人打交道。

立场 – 屁股决定脑袋

要学会问为什么，但是重要的是要去理解项目背后的意图，有时候一个项目往往是先有蛋再有鸡，这种时候要做的是和产品站在同一个立场进行思考，做项目的时候要找到自己的立场，外部教练可以不计成本地推翻原有的一切，追寻最好的解决方案，而我们往往要找到这个最优解在部门现实情况中落地的最优解。难上加难，却不得不做。

态度 – 易者易为，难者难为

在一个项目中，每一个人都有自己的一块蛋糕，当然每个人都想要守住自己的蛋糕，这个是完全没有问题的，所以新进入一个项目中首先要找到自己的发力点，态度一定要积极，此时切莫眼高手低，把手上的能找到的事情做好，再慢慢寻找新的机会。

术

理清问题域与解决方案域

在领域建模中有一种战略设计方法论叫分清问题域和解决方案域，而这个方法论的关键在于让大家在分析问题时不要陷入问题解决方案，而要先抓住问题主旨。举个例子桌子腿断了站不稳是个问题，但是可以通过垫东西来解决也可以通过重新买一个桌子来解决。这个方法同样适用于一般问题的分析，在进入一个新的项目时，要先分析清楚自己面临的问题是什么，而不要盲目地去干活。

业务专家

如果业务专家能够现身说法那是一种幸运，如果没有那是一种常态。

在我司大家都很忙，业务专家往往是一个产品的轴心，进到一个新项目后和业务专家的交流机会大概会有个0到两次。交流的时候要关注历史，业务专家一般都能把这个产品的前世今生给讲个明明白白，但他们可能不太清楚现在实现的具体细节，所以在和业务专家交流的时候不用过分关注实现细节，要把重心放在理解系统设计上，可以多关注系统上下文的设计以及API。

产品文档

产品文档可能是我们最全面了解产品现状的途径，通过产品文档可以得到以下信息：

• 产品背景和主要业务
• 产品的硬件和软件结构，包括整体解决方案，系统架构等
• 产品的组网和周边产品的接口

了解这些能够快速帮助你了解产品的业务背景和一些产品的专业术语对其，一般来说花个几个小时就可以搞定。另外通过产品文档我们可以尝试亲手搭建环境，搭环境是比较直观和全面地了解一个产品的手段，但是也比较耗时。

产品架构设计文档

一般来说，产品都会有类似于逻辑架构设计说明书的文档，这个可以帮助你快速了解产品的逻辑架构。通过架构设计文档可以了解到各个子系统的主要功能和职责，以及各个子系统的大概交互方式。

阅读代码

前期准备

• 了解编程语言、编程框架(使用了Akka，OscarGo，Spring等框架，或者是基于什么微服务架构)，使用的平台(Dopra，CSP等)。

• 了解一个产品的领域模型和产品实现的时候对应的软件模型，打个比方，如果是做一个电商系统，典型的领域对象就是购物车，物流，商品目录等，我们需要找到代码中和这些关键领域概念的对应关系，这样也可以防止在后续修改代码时无意间破坏了领域模型。

• 阅读测试集，敏捷开发中强调代码即文档，测试集往往就承当了这个“即文档”的功能，测试集反映了一个产品的对外契约(当然这里说的是测试做的好的产品)。但是从我接手的项目的经验来看，拥有好的测试集的产品是凤毛麟角，相反开源代码一般来说测试集都很比较充分和友好的。

阅读代码方式

• 先了解产品的代码目录结构，通过目录结构来了解代码的物理模块划分

• 代码调试，搭建物理环境有助于理解组网，理解系统级架构，而代码调试则会更快地理解代码骨架，但是代码调试很容易会让人陷入细节，所以在代码调试的时候可以先不细究函数里面每一步具体的实现，对于有疑问的可以看一下。

• 静态阅读代码，这个时候其实可以通过一些类设计器生成代码类图(vs支持，其他不清楚)，或者是手绘(我比较喜欢手绘，因为这样只需要关注自己想要关注的局部)。

• 日志是个好东西，跑一个主要业务流程，分析它的打印，找到对应的代码，而且日志有一个好处是可能会记录从启动开始的基础组件的打印，这样也可以更全面地了解这个系统。不过有些系统对于日志打印条目极为苛刻(例如核心网)，那这种系统就不太适合通过日志来上手。

总结

以上是我进入一个新项目进行需求开发的处理方法，过去也和Thoughtworks长期做技术咨询类的专家一起合作并做过相关的交流，也了解了一些他们的方法和手段。

总的来说，要掌握一个新技术，最快捷的方法就是搞清楚它为什么出现，然后找到问题的核心点，花时间去理解最关键的地方(虽然这里只是一句话飘过，但是这里可能代表了无数掉头发的通宵日子)。要学会抽象和抽丝剥茧，不要把精力分散在周边。

经验有限，如果有说的不对的地方，欢迎随时交流。