20人年的项目2个星期交接，你从哪里入手？

作为程序开发人员，具备学习新知识的能力非常非常重要。这是由IT领域的特殊性决定的。我们所面临的新知识不仅包括新语言、新技能、新工具，也可能会是一个全新的项目，甚至是全新的开发环境。最近，我身边的一位同事就遇到了一个这样的难题：由于组织架构调整，一个20人年的项目需要2个星期内交接到他手上。这是一个纯粹的商业项目，前边有customers不断提出问题，后边有公司领导不断“关心”状态更新，其压力可想而知。让我们设想一下，如果你处于这样的环境，你会怎么做？如何才能快速上手一个陌生系统呢？

关于这个问题，我先来谈谈自己的体会。其中一些观点是近10年来类似经验的总结，也包括一些身边朋友的心得分享。

首先，我能想到的是要熟悉业务背景，也就是industry background knowledge，因为再没有什么别的比搞清楚你要做什么更重要了。不同的业务逻辑需要不同的软件架构支撑，需要处理不同的work flow。尽量的去熟悉业务背景能够让你更加清楚你所面对的项目需要解决什么样的具体问题，能够帮你快速建立关于当前项目的一个大的picture。磨刀不误砍柴工，再怎么着急，也要请你从这一步开始。

接下来干什么呢？一头扎到代码里边？别着急啊！问一问有没有关于架构设计的文档。因为接下来你需要的是从宏观上理解软件的架构，从大的层次上理解软件的结构，了解软件有哪些模块组成。这些模块是如何配合工作的？在进行任何细致工作之前，你需要先勾勒出项目的粗线条。几乎所有的软件项目都离不开输入/输出以及数据的流动。先搞清楚data是如何在各个layer或者module之间传递，大体上需要什么样的逻辑功能来处理这些data。

经过以上两步，你算是对手头项目有了一个大体的认识。但是到此为止，你所有的认识还只是停留在静态文档的基础上。接下来，按照我的经验，你就要尽快的让程序动起来----搭建好开发环境，准备好有代表性的sample input data，具体地调试进去。这时候，F5+F10+F11(VS)是你最好的帮手。好的代码结构会尽可能清晰地表达程序的处理流程。当然，你不可能指望简单地通过几个循环就完全掌握别人几个月甚至几年的工作积累。但是，动态调试帮助你真正地走到程序内部去一窥究竟。一旦对程序有了总体认识之后，我的个人感觉是debug来的越早越好。初期的调试尽量结合架构的认识去理解程序，不要再细节浪费过多的时间。遇到不太明白的地方先跳过，多次出现的核心对象先记载下来回头再仔细研究。

经过几轮初期调试之后，你会直观地感受到程序的流程，但是很多具体的东西还是不太清楚。这时候，作为一个有心人，你会积攒出一大堆的问题。不断出现的几个核心对象，他们究竟是如何工作的？类与类之间的关系是如何设计的？用到了哪些设计模式？程序的数据对象是如何表达的？这些都已经是比较具体的问题了。能提出具体的问题才说明你的认识到了一定具体的层次。这时候如果具有良好的OOD和OOP经验往往会会引导你往下思考。为了深入地剥丝抽茧，建议你不要停下来。打开UML工具尝试着分析一下核心class的结构层次。深入理解核心类型的核心方法（算法）。具体分析一下数据模型的如何设计和包装的。数据模型搞清楚了之后，可以尝试着修改数据后看看程序是如何反应的，验证一下自己理解的是否正确。等等，等等。

其实在有限的时间里了解一个陌生系统，除了正确方法之外，还要能够抓住重点。找到程序本身的pain points，看看那些是客户反映最多抱怨最大的问题，这个也是作为项目本身需要你去着力解决的问题。

编程是门科学，但是代码的组织和分析却是门艺术。掌握一个新项目往往能能考验一个人对新事物的理解能力。快速地理解能力离不开长时间的开发经验积累，当然还有那一丝对于代码本身的灵感。学无止境，阅读和维护别人的代码也是一种很好的学习方法。