在ThoughtWorks里面，我经常有机会在不同的项目组间轮换，所以，经常会面对陌生的一切，出去做咨询项目时也是如此。但人们常常会对有经验的人加入项目有所预期，也就需要我能够尽快进入到工作状态中。所以，我也就慢慢摸索出一套适合自己的了解项目的方式。

   业务

   首先，肯定要从业务入手，了解这个系统是做什么的。既然是初始的接触，我并不预期弄清楚所有的细节，只要知道这个系统是做什么的基本上就够了。

   按理说，这通常不应该是什么问题，但这也是常常容易出问题的地方，比如说，有为数不少的人在讲业务的时候，会把技术的内容混在一起讲，这一点对于技术人员尤为明显。个人就曾经经历过让我开始怀疑自己智商的几次介绍。如果5分钟说不清楚，你就别指望半个小时能说清楚。

   技术

   了解了系统的业务，接着就是对技术方面的了解。还是先从宏观方面入手，我期望了解到这个系统是由哪个技术栈实现的，Java、C/C++还是.NET系等等。这样，我就可以系统采用相应的工具与框架有个大概的预期。

   接下来，我期望从架构层面上了解系统。有没有一张或几张图能够把整个系统描绘出来，比如，这个系统需要与几个外部系统集成，自身包括哪些部分等等。一般我不指望有现成的图，多半的情况是，其他人一边说，一边在白板上画出一副这样的图。我接下来会根据自己的理解，把需要的这种图画出来。

   对大面的东西有了了解，我就希望稍微了解一下细节。从集成开始，因为输入输出对一个系统来说是非常重要的，而集成点往往都是系统信息来源。如果有集成，集成方式是什么，比如，Web Service、RMI、MQ，有为数不少的系统用的是FTP，这些集成方式相当于信息的承载，那之上的信息是什么样子，我们还需要搞清楚，比如有的系统用的是MQ，在MQ上传的是XML等等。接下来，就是更具体的协议层面的东西了，我想知道是否有对应的文档，这样，我在需要的时候，就可以查看每个字段具体的含义，不过，这往往不是初期要了解的东西。

   了解了集成，接下来就是系统内部了。这个系统有哪些子系统或模块组成。好的系统往往是由多个进程构成的，这样才不会彼此影响。对于这样的系统，我只要了解每个子系统的作用就可以了。而对于那些只有一个进程的系统，我就需要了解一下这个系统包含哪些模块，各个模块承担着怎样的职责。通常，这会一个很重要的出问题的点，因为很多系统虽然号称有模块的概念，但模块之间的职责往往是不清楚的，经常会出现很严重的依赖问题。对于现代软件系统而言，分层结构往往是不可或缺的，我还希望了解一下这个系统有多少个层，每个层做的事情是什么。这里提及了模块和层次，模块通常是从业务上来分，而层次往往是从技术上看，一个水平一个垂直。

   从设计层面了解完，就是动手的层面了，不过，还不是写代码的事。我会先了解构建脚本。了解一下项目中常用的命令，比如，是否可以一键式跑脚本提交之类的。我期望看到的是一个从版本管理工具里拿出来直接可以构建成功的脚本。但通常情况都不是这样的，要改很多东西、配不少的东西。这也许就是未来要改进的东西。

   熟悉了周边的东西，我们就可以深入到源码层面了。这就是我们程序员最熟悉的东西，比如，源码目录结构、配置文件的位置、模块在源码上的体现之类的等等。但作为最初的接触，我们只要了解基本的东西就够了，因为这是我们后来投入精力最多的地方，以后深入理解的机会多得是。

   团队运作

   除了了解技术层面的东西，我还希望了解团队运作方面的东西，一个方面就是常见活动的时间安排，比如，站会、迭代计划会议、回顾会议等的时间。再有一个方面就是，团队内部是否一些活动安排，比如是否有每天的Code Diff，是否有常规的Session墙。如果团队有外部客户，我们有客户日常的沟通是怎样进行的。

   通过这些问题，我们便不难发现项目运作上的一些问题，比如，很多团队与客户之间根本没有常规的沟通，只是会临时起意去做沟通。有的团队没有Session墙，团队内部分享也就没有常规化。

   通常以上这些东西都不需要很长的时间来了解，快的话，一天就可够了。而通过这些了解，我就可以对团队的基本情况有了一个相对完整的大体认识，接下来的事，就是卷起袖子开始干活了！

建议继续学习：

1. 项目中：覆巢之下，岂有完卵    (阅读：2565)
2. 把项目当做产品来做    (阅读：2183)