今天这篇文章一行代码都没有请放心阅读。
无论是换工作，换团队，还是换业务，我们都不可避免地会接触新的项目，甚至可能接触一个大型的项目。很多人，包括我自己，在面对这一整个庞大的工程的时候，未免会感觉到有点力不从心，有点焦虑，因为毕竟是一个全新的东西，它有自己的生命，自己的问题，自己的功能，自己的架构。
我经常在想，有没有一套方法，可以让我们快速进行项目工程呢？
答案是有的，最近逐渐在脑子里成型。
项目工程，我们不外乎关注这么几个点。
1、这玩意干啥的？怎么做到的？
2、这玩意我咋上手？
3、这玩意我改得动吗？不会崩吗？
很遗憾的是，很多人其实只关注了第二点，也就是我经常说的 ctrl c + ctrl v 工程师。很多的时候你并不知道为什么这样写，为什么只能这样写，当时为什么会这样写。听过一个笑话，就是你觉得一坨代码很烂，但是你深思熟虑后，觉得也只能这样写了。
我们关注的几个点要怎么到达呢？我建议是这么一个路径去达到。
首先，咨询原来的开发者，得到整个项目的背景以及项目的历史，和各个部分的关系。这一步，我们可以在脑子里有个大概，但是很显然一个组件都记不住，关系也记不住，但是没关系，我们来到第二步。
这个时候，你脑子里必然是一脸懵逼的，我们的经验和大脑本能地告诉我们这事情是行不通的，但是别人又说这是行得通的，这在我们脑子里就很矛盾，你需要一些证据给你的大脑证明这是行得通的。所以这时候你需要一个 quick start，也就是 ctrl c + ctrl v 按照前辈的经验自己写一个小功能，也就是一个证据，一个就够了。接下来就开始分析我们的需求改动点应该是哪里了。
这玩意我改得动吗？这是我们的脑子给我们的第三个信号，它在不熟悉一个东西的时候，会本能地拒绝任何的变更。所以在这个阶段，源码阅读是我们必不可少的一个步骤，特别是在项目开发的过程中，我们要依靠第一步的系统关系，以及我们已经认知的业务流程，把项目代码啃下来。就是我们已经知道有ABCDE子系统以及他们的大概关系，利用这个关系，像编织篮筐一样，按照设计的方向慢慢看清整个项目。
阅读源码的过程 以接口和消息机制为入口，仔细梳理某个流程的完整调用链，并把它扩展到其他的调用过程里面。相信我，绝大部分的代码都是增删改查，你要了解的事情是，这是在哪查的，在哪改的，在哪删的，在哪增的，这就够了。至于业务流程本身，或者逻辑判断，有个大概的认识就好了，第一遍阅读主要是认一认各个系统各个数据结构之间的关系，让你的脑子知道这玩意是怎么跑的。
基于第一次阅读的认识，我们再反向观察整个项目结构，这时候的你不仅有信心，而且知道项目整体情况，对于各个部分的细节也有一定的认识，你的项目眼界不知不觉中已经提高到一个架构师的基本。这时候的你必然能得到你所负责需求的改动，以及对于全局的影响。
大系统就是这样，牵一发而动全身。
随时随地看视频
