不要事无巨细地请教老同学，要有Owner的心态

淘系技术部-淘系架构-光锥

在接手一个自己不太熟悉的新项目时，可以从以下几点思考以便快速熟悉系统。

熟悉业务

用户是谁、提供的核心功能是什么、系统在上下游的地位是什么。

不涉及具体的实现细节，通过核心功能产品层面的熟悉，能够对项目有一个全局性把握。

熟悉部署结构

最新的代码在哪，测试环境如何搭建，监控告警有哪些，线上如何部署，线上机器分布情况等等，通过自己亲自发布一次代码，观察哪些指标，了解整体的发布流程以及部署情况。

从问题中学习

系统较为复杂时，实现细节太多，直接上手看代码熟悉链路的实现细节效率较低，比较好的方式是通过实际问题，了解一个问题的来龙去脉，通过具体问题的修复过程中，逐步熟悉整个系统，但需要把熟悉的部分整理到整体的认识当中。就好比玩一款拼图游戏，一个局部一个局部拼好，但心中始终要有一个全景视图，把局部的拼图一点点归纳到整体视图中。

owner的心态

接手一个系统，就需要以owner心态对待。

有些同学习惯性的事无巨细都请教老同学，心底有所依赖，缺少了一份独立思考，成长起来就相对较慢。

遇到疑问要首先要自己做一个判断，不论判断的是否正确，经过一次思考后，对系统的理解将会上一个台阶。

如果是我应该怎么做

在熟悉系统的过程中，可以多问一下，如果是我来设计这个项目，或者由我来实现这个功能，应该怎么做。

原有的项目可能由于历史原因，并不是以最优方式实现，对比自己期望的做法，可以快速了解到系统这样做的深层原因。

通过一次次对自己的追问中，可以更快的理解系统的深层背景，同时增加自身的设计能力。

而自己原有的技能，也能更好的反馈在新的项目当中。

认识各类大中型项目演进历程，有助于你真正理解一个项目

淘系技术部-淘系架构-家愿

工作多年，大中小型项目均经历过，分享一些我的经验。

首先，谈谈中大型项目是如何演进的。

部分中大型项目是慢慢演进而来的，这些项目一般都是从小项目或者相对简单的架构演变而来的，随着需求的叠加或当前的架构已不能支持用户规模逐步演变而来的。

演进方向一般都是从：单体-SOA-微服务-云原生。

这类项目因时间周期长，迭代次数多，需求文档和设计文档一般都会存在缺失，一般都是文档落后于实现，且这类项目一般都有一些坑或者历史包袱，很难直接通过文档就直接将项目做到了然于心。

另一部分中大型项目则是近期设计开发完成，周期不是很长，一般是两年内的项目，这类项目因为是近期设计且中大型项目业务或架构都会相对比较复杂，在开发前都是经历了较为完整与严格的需求评审、技术选型/评审的，沉淀的文档和线上代码一般差距不会很大。

因为在设计之初就定位为中大型的项目，需求和设计一般在一开始就想的比较清楚了才会进行开发，初期功能上线后，后面的迭代升级一般不会在技术上进行大改，一般都是要么按照需求文档，将功能分期上线，要么就是一些小问题的修复，所以这类项目一般通过文档就能对项目进行一个整体的把控。

当然我们肯定乐意接触的项目都是后者，但是往往并不是事事都能如意，那么针对前者这种文档相对缺乏的项目，我们如何快速切入呢？

下面我们谈谈如何快速熟悉一个项目。

我们首先要了解业务背景，大部分情况下，技术都是为业务服务的，业务优先于技术，一般来讲，我们可以认为业务是一种商业模式，我们了解业务背景，其实本质上是了解这个业务背后的运转模式，基于运转模式进行深入。其实变相的就对整个系统进行了了解。

举个例子：比如我们接手了一个Push消息系统（消息推送），那么我们需要先知道Push是什么以及Push的运转模式，Push是什么？

Push可以简单认为是一种触发用户的方式，我们通过Push触达终端设备从而起到一个通知提醒的作用，一般情况下Push指的是无线设备上的应用通知。

Push的运转模式是怎样的呢，整个链路是怎样的呢？

我对Push的整个链路进行了一个抽象：消息请求-消息受理(分发)-消息送出-消息到达-消息曝光-消息点击-后续业务转化，其中部分链路可以进行合并（例如消息受理和消息送出，但大致链路遵守这个模式）。

将整个Push的链路抽象出来后，我们接下来就可以针对各个链路进行进一步的了解，比如我们想要了解消息送出，那么我们就会问消息是如何送出的？送出给谁？

在AppPush下，消息送出一般指投递给具体的通道（包括自建通道和厂商通道），那么是如何投递的呢？

我们接下来就去了解各个通道是如何提供服务的，是基于什么技术，我们需要如何使用，这样就把通道送出的大致原理搞明白了。

其实整个思路也是遵循了总分总的模式，我们首先了解项目的整体业务背景，整体的运转模式，然后基于运转模式里的各个点再进行深入了解，然后总结各个点，最后达到对整个项目有个整体的认知的地步。

运转模式其实是对业务的一个抽象，如果接手的项目没有直接的文档，那么可以通过实际上手使用相关功能或者咨询相关产品/运营同学了解，然后再自己归纳验证，整个过程下来，你就对这个项目是做什么的，用户是谁就有了一定的了解，我们接下就可以谈谈如何上手

在了解了项目的运转模式后，我们针对代码如何上手呢？

我们不要一上来就逐行去读源码，这样不仅效率低，而且容易一下子就陷入到细节中把自己绕晕，那么我们应该怎么做呢？

首先我们需要提前了解公司常见的技术，开发部署环境、常用中间件、DB等，对公司的技术有个大致的了解，和市面上相似的技术进行比较，了解每个技术的优缺点，这样我们后面才能知道为什么会用这个技术。

其次我们要寻找整个项目的重点和难点在哪里，针对一个有一定开发经验的同学，我们在了解到项目的运转模式后，我们可以想想，如何是让你来设计实现整个项目，你会怎么做，技术选型会如何选，哪里可能不好设计，哪里可能存在挑战。

在想清楚这个问题后，再来验证当前项目的技术架构是否与预想一致，不一致的地方想办法弄清楚为什么，项目的技术架构如何获取呢？

项目是由各个应用组成的，各个应用有自己的模块，各个应用的职责是什么一般很容易获取到，公司内部一般都能找到应用的描述，但是自己的模块划分怎么获取到呢？

如果有相关文档那当然很容易，但是如果没有文档，我们可以尝试问问同事了解，如果上述两招都不好使，只有代码，那我们只能从代码着手了。

好的设计可以直接从工程的目录结构上了解到应用的模块分类，从命名上知道模块大致的作用，其次我们可以从pom文件、打包脚本、接口类等对应用模块以及提供的服务能力进行初步了解（这里以Java工程为例），同时进行到这一步后，我们可以将应用以及应用内模块的功能进行了一个整理，形成一个文档；这样当我们需要实现一个需求或者需要修Bug的时候，我们可以快速知道这个功能可能需要涉及哪些应用以及模块。

最后就是进行实战了，在我们了解项目的运转模式后，我们对项目的架构、技术有了初步的了解，那么我们可以上手一个小需求了，或者尝试改改小bug，这时候才是我们需要扣细节的时候。

我们接到需求后，思考涉及的应用以及模块，然后去看当前这些模块的实现，搞懂相关的实现，如何搞懂呢？

有一些很好的实践，例如在本地完成工程的搭建后，针对代码进行debug（debug有很多小技巧可以提升效率，例如远程debug、条件断点等，可以现在网上进行学习掌握），了解每步实现的处理和数据变化，从而完全掌握这一个小模块或功能点的实现，这样在心中有数后，就可以愉快的将小需求进行开发了，多做几个小需求后，对应用的细节也就慢慢熟悉起来了。

十分推荐在项目熟悉了解过程中沉淀自己的资料

淘系技术部-前端技术-阮萤

时逢转岗到淘系一年的时间，正好借此机会来讲讲自己是如何落地一个全新业务和技术栈的项目。

十分推荐在项目了解过程中将自己了解的内容沉淀成资料，来明确和巩固自己的了解情况，同时有助自己和他人后续回顾。整个了解过程由粗到细主要分为三步：

第一步，了解业务

在上手新项目前，如果对该项目所在的业务并不了解，那么先大致了解下整体业务，以及新项目在整体业务中所处的位置，能帮助你后续更快了解新项目。可以重点

转载请注明:http://www.aideyishus.com/lktp/2837.html