作为开发⼈员，我们不可避免地会遇到如下场景，⼀是接⼿前同事的项⽬，⼆是参与到新的项⽬组开发。
如果项⽬不紧急留给我们时间去了解业务还好，⼀旦项⽬紧急，则会让我们感觉到压⼒⼭⼤。这个时候必须要有⼀套⾏之有效的⽅案，能够引导我们快速步⼊正轨。 成熟的程序员，擅⻓从过往经验⾥总结出快速上⼿和熟悉新项⽬的技巧。
下面记录了4名淘系技术⼯程师分享的⼀些他们在接⼿新项⽬时的⽅法⼼得，希望对换⼯作或者换业务的你有帮助。
不要事⽆巨细地请教⽼同学，要有Owner的⼼态。
淘系技术部 · 淘系架构 · 光锥
在接⼿⼀个⾃⼰不太熟悉的新项⽬时，可以从以下⼏点思考以便快速熟悉系统。
熟悉业务
⽤户是谁、提供的核⼼功能是什么、系统在上下游的地位是什么。
不涉及具体的实现细节，通过核⼼功能产品层⾯的熟悉，能够对项⽬有⼀个全局性把握。
熟悉部署结构
最新的代码在哪，测试环境如何搭建，监控告警有哪些，线上如何部署，线上机器分布情况等等，通过⾃⼰亲⾃发布⼀次代码，观察哪些指标，了解整体的发布流程以及部署情况。
从问题中学习
系统较为复杂时，实现细节太多，直接上⼿看代码熟悉链路的实现细节效率较低，⽐较好的⽅式是通过实际问题，了解⼀个问题的来⻰去脉，通过具体问题的修复过程中，逐步熟悉整个系统，但需要把熟悉的部分整理到整体的认识当中。
就好⽐玩⼀款拼图游戏，⼀个局部⼀个局部拼好，但⼼中始终要有⼀个全景视图，把局部的拼图⼀点点归纳到整体视图中。
owner的⼼态
接⼿⼀个系统，就需要以owner⼼态对待。
有些同学习惯性的事⽆巨细都请教⽼同学，⼼底有所依赖，缺少了⼀份独⽴思考，成⻓起来就相对较慢。
遇到疑问要⾸先要⾃⼰做⼀个判断，不论判断的是否正确，经过⼀次思考后，对系统的理解将会上⼀个台阶。
如果是我应该怎么做
在熟悉系统的过程中，可以多问⼀下，如果是我来设计这个项⽬，或者由我来实现这个功能，应该怎么做。
原有的项⽬可能由于历史原因，并不是以最优⽅式实现，对⽐⾃⼰期望的做法，可以快速了解到系统这样做的深层原因。
通过⼀次次对⾃⼰的追问中，可以更快的理解系统的深层背景，同时增加⾃身的设计能⼒。
⽽⾃⼰原有的技能，也能更好的反馈在新的项⽬当中。
认识各类⼤中型项⽬演进历程，有助于你真正理解⼀个项⽬
淘系技术部 · 淘系架构 · 家愿
⼯作多年，⼤中⼩型项⽬均经历过，分享⼀些我的经验。
⾸先，谈谈中⼤型项⽬是如何演进的。
部分中⼤型项⽬是慢慢演进⽽来的，这些项⽬⼀般都是从⼩项⽬或者相对简单的架构演变⽽来的，随着需求的叠加或当前的架构已不能⽀持⽤户规模逐步演变⽽来的。
演进⽅向⼀般都是从：单体 -> SOA -> 微服务 -> 云原⽣。
这类项⽬因时间周期⻓，迭代次数多，需求⽂档和设计⽂档⼀般都会存在缺失，⼀般都是⽂档落后于实现，且这类项⽬⼀般都有⼀些坑或者历史包袱，很难直接通过⽂档就直接将项⽬做到了然于⼼。
另⼀部分中⼤型项⽬则是近期设计开发完成，周期不是很⻓，⼀般是两年内的项⽬，这类项⽬因为是近期设计且中⼤型项⽬业务或架构都会相对⽐较复杂，在开发前都是经历了较为完整与严格的需求评审、技术选型/评审的，沉淀的⽂档和线上代码⼀般差距不会很⼤。
因为在设计之初就定位为中⼤型的项⽬，需求和设计⼀般在⼀开始就想的⽐较清楚了才会进⾏开发，初期功能上线后，后⾯的迭代升级⼀般不会在技术上进⾏⼤改，⼀般都是要么按照需求⽂档，将功能分期上线，要么就是⼀些⼩问题的修复，所以这类项⽬⼀般通过⽂档就能对项⽬进⾏⼀个整体的把控。
当然我们肯定乐意接触的项⽬都是后者，但是往往并不是事事都能如意，那么针对前者这种⽂档相对缺乏的项⽬，我们如何快速切⼊呢？
下⾯我们谈谈如何快速熟悉⼀个项⽬。
我们⾸先要了解业务背景，⼤部分情况下，技术都是为业务服务的，业务优先于技术，⼀般来讲，我们可以认为业务是⼀种商业模式，我们了解业务背景，其实本质上是了解这个业务背后的运转模式，基于运转模式进⾏深⼊。其实变相的就对整个系统进⾏了了解。
举个例⼦：⽐如我们接⼿了⼀个Push消息系统（消息推送），那么我们需要先知道Push是什么以及Push的运转模式，Push是什么？
Push可以简单认为是⼀种触发⽤户的⽅式，我们通过Push触达终端设备从⽽起到⼀个通知提醒的作⽤，⼀般情况下Push指的是⽆线设备上的应⽤通知。
Push的运转模式是怎样的呢，整个链路是怎样的呢？
我对Push的整个链路进⾏了⼀个抽象：消息请求 -> 消息受理(分发) -> 消息送出 -> 消息到达 -> 消息曝光 -> 消息点击 -> 后续业务转化，其中部分链路可以进⾏合并（例如消息受理和消息送出，但⼤致链路遵守这个模式）。
将整个Push的链路抽象出来后，我们接下来就可以针对各个链路进⾏进⼀步的了解，⽐如我们想要了解消息送出，那么我们就会问消息是如何送出的？送出给谁？
在App Push下，消息送出⼀般指投递给具体的通道（包括⾃建通道和⼚商通道），那么是如何投递的呢？
我们接下来就去了解各个通道是如何提供服务的，是基于什么技术，我们需要如何使⽤，这样就把通道送出的⼤致原理搞明⽩了。
其实整个思路也是遵循了总分总的模式，我们⾸先了解项⽬的整体业务背景，整体的运转模式，然后基于运转模式⾥的各个点再进⾏深⼊了解，然后总结各个点，最后达到对整个项⽬有个整体的认知的地步。 运转模式其实是对业务的⼀个抽象，如果接⼿的项⽬没有直接的⽂档，那么可以通过实际上⼿使⽤相关功能或者咨询相关产品/运营同学了解，然后再⾃⼰归纳验证，整个过程下来，你就对这个项⽬是做什么的，⽤户是谁就有了⼀定的了解，我们接下就可以谈谈如何上⼿。
在了解了项⽬的运转模式后，我们针对代码如何上⼿呢？
我们不要⼀上来就逐⾏去读源码，这样不仅效率低，⽽且容易⼀下⼦就陷⼊到细节中把⾃⼰绕晕，那么我们应该怎么做呢？
⾸先我们需要提前了解公司常⻅的技术，开发部署环境、常⽤中间件、DB等，对公司的技术有个⼤致的了解，和市⾯上相似的技术进⾏⽐较，了解每个技术的优缺点，这样我们后⾯才能知道为什么会⽤这个技术。
其次我们要寻找整个项⽬的重点和难点在哪⾥，针对⼀个有⼀定开发经验的同学，我们在了解到项⽬的运转模式后，我们可以想想，如何是让你来设计实现整个项⽬，你会怎么做，技术选型会如何选，哪⾥可能不好设计，哪⾥可能存在挑战。
在想清楚这个问题后，再来验证当前项⽬的技术架构是否与预想⼀致，不⼀致的地⽅想办法弄清楚为什么，项⽬的技术架构如何获取呢？
项⽬是由各个应⽤组成的，各个应⽤有⾃⼰的模块，各个应⽤的职责是什么⼀般很容易获取到，公司内部⼀般都能找到应⽤的描述，但是⾃⼰的模块划分怎么获取到呢？
如果有相关⽂档那当然很容易，但是如果没有⽂档，我们可以尝试问问同事了解，如果上述两招都不好使，只有代码，那我们只能从代码着⼿了。 好的设计可以直接从⼯程的⽬录结构上了解到应⽤的模块分类，从命名上知道模块⼤致的作⽤，其次我们可以从pom⽂件、打包脚本、接⼝类等对应⽤模块以及提供的服务能⼒进⾏初步了解（这⾥以Java⼯程为例），同时进⾏到这⼀步后，我们可以将应⽤以及应⽤内模块的功能进⾏了⼀个整理，形成⼀个⽂档；这样当我们需要实现⼀个需求或者需要修Bug的时候，我们可以快速知道这个功能可能需要涉及哪些应⽤以及模块。
最后就是进⾏实战了，在我们了解项⽬的运转模式后，我们对项⽬的架构、技术有了初步的了解，那么我们可以上⼿⼀个⼩需求了，或者尝试改改⼩bug，这时候才是我们需要扣细节的时候。
我们接到需求后，思考涉及的应⽤以及模块，然后去看当前这些模块的实现，搞懂相关的实现，如何搞懂呢？
有⼀些很好的实践，例如在本地完成⼯程的搭建后，针对代码进⾏debug（debug有很多⼩技巧可以提升效率，例如远程debug、条件断点等，可以现在⽹上进⾏学习掌握），了解每步实现的处理和数据变化，从⽽完全掌握这⼀个⼩模块或功能点的实现，这样在⼼中有数后，就可以愉快的将⼩需求进⾏开发了，多做⼏个⼩需求后，对应⽤的细节也就慢慢熟悉起来了。 ⼗分推荐在项⽬熟悉了解过程中沉淀⾃⼰的资料
淘系技术部 · 前端技术 · 阮萤
时逢转岗到淘系⼀年的时间，正好借此机会来讲讲⾃⼰是如何落地⼀个全新业务和技术栈的项⽬。
⼗分推荐在项⽬了解过程中将⾃⼰了解的内容沉淀成资料，来明确和巩固⾃⼰的了解情况，同时有助⾃⼰和他⼈后续回顾。整个了解过程由粗到细主要分为三步：
第⼀步，了解业务 在上⼿新项⽬前，如果对该项⽬所在的业务并不了解，那么先⼤致了解下整体业务，以及新项⽬在整体业务中所处的位置，能帮助你后续更快了解新项⽬。可以重点关注与新项⽬有关的上下游业务。 过程中可以产出：业务⼤图、整体业务流程图。
第⼆步：了解项⽬/产品
功能&流程：通过试⽤项⽬对应的产品先建⽴对项⽬功能和流程的初步概念。 技术架构：通过项⽬现有设计资料并结合表结构、重点功能代码、鹰眼调⽤链信息等了解新项⽬的技术架构。 过程中可以产出：项⽬业务流程图、系统架构图、数据模型、重点逻辑流程图。
第三步：了解技术栈
如果新项⽬是和前项⽬完全不同的技术栈，那么你还需要了解新项⽬所在的技术⽣态。通过开发⼀个⼩功能来了解和熟悉新项⽬的项⽬⻛格和依赖的技术产品是不错。 从⼩需求开始，尝试编码和逐步矫正
淘系技术部 · 前端技术 · 正期
我总结下⾃⼰的经验，⼤概有如下⼏个步骤，简单做下分享：
第⼀步，了解项⽬架构，按照服务划分模块（预计耗时两天）
接⼿新的项⽬，⼀定是先了解项⽬架构；后端多以服务划分模块，所以我们以服务为维度对项⽬划分模块。
⼀般规范的项⽬，已经存在有⽐较完善的项⽬⽂档，可以快速了解项⽬的主要模块，形成⼤概的印象。
每个模块⼀般对应了⼀个git仓库代码，这时候必须记录下对应关系，这样给到某个需求的时候，我们才能知道具体的功能实现在哪个仓库中。
在这个过程中，⼀定不能只看，要动⼿做记录，可以是画流程图，可以是记录⽂档。否则看过⼀眼之后很容易忘记。
第⼆步：找准核⼼业务链路，将模块串起来，⾛读代码（预计耗时两天）
什么是核⼼业务链路呢？核⼼业务链路是指系统提供的主要服务的代码调⽤链路。
为什么选取核⼼业务链路研究呢？因为核⼼业务⼀般是由核⼼模块之间调⽤完成，研究完之后我们能够快速对核⼼模块有更加深刻的认识。
以⼿机中台为例，最核⼼的就是将⼿机的屏幕数据以视频流的⽅式传递给⻚⾯侧展示，这中间涉及
- session-server模块提供的会话服务；
- ⽤户侧拿到 session 之后 websocket 直连 device-agent 模块；
- 设备侧的屏幕数据流采集和 h264 视频编码；
- ⽹⻚侧的播放器模块实现播放；
看懂这些模块后，基本也就对⼿机中台的核⼼模块有个⼤概了解了。 同样，这个过程需要进⾏画流程图加深印象。
第三步：从⼩需求开始，尝试编码
我们很容易⾛进⼀个误区，就是觉得⾃⼰对项⽬还不了解，不着急做需求。
其实⼀直看⽽不做，反⽽印象不深刻，为了学⽽学，总是收效甚微；相反，带着具体问题去看，逐步踩坑，才能快速上⼿；因为有些问题不做是不会发现的，⽐如代码规范问题，不去写，我们永远不知道⾃⼰和规范差多远，这是个逐步矫正的过程。
刚开始做的⼩需求不⽤求快，⽽是以规范为主。做完之后有了成就感，对我们也是⼀种正向激励。
总结
所谓“磨⼑不误砍柴⼯”，淘系⼯程师推荐⼤家从项⽬本质出发，了解项⽬背后的业务，然后对业务模式进⾏抽丝剥茧，和应⽤实现相互对照，最后熟悉项⽬后，进⼀步通过完成需求来实现业务，并积极总结沉淀属于⾃⼰的理解内容和资料⽂档。
happy coding!
NOTE
本文为转载，原文链接：程序员如何快速上手一个新项目？