不要每一个细节都请教老同学，要有主人翁的态度。
淘大技术部-淘大建筑-光锥
在接手一个不熟悉的新项目时，为了快速熟悉系统，可以从以下几点思考。
熟悉业务
用户是谁，提供的核心功能是什么，系统在上下游的位置是什么。
不涉及具体的实现细节，通过对核心功能产品的熟悉，可以对项目有一个全局的把握。
熟悉部署结构
最新代码在哪里，如何设置测试环境，有哪些监控告警，如何在线部署，在线机器分布等。通过自己发布代码，观察哪些指标，了解整体发布流程和部署。
从问题中学习
系统复杂的时候，实现细节太多，直接看代码，熟悉环节的实现细节，效率很低。比较好的方法是通过实际问题了解一个问题的来龙去脉，通过修复具体问题的过程逐渐熟悉整个系统，但是需要把熟悉的部分整理成整体的认识。这就像玩拼图游戏，其中一个部分拼得很好，但一个人心里必须时刻有一个全景，把局部的拼图一点一点总结成整体的视图。
业主心态
接手一个系统，你需要用主人的心态去对待。
有些同学习惯性地向老同学请教每一个细节，但他们相互依赖，缺乏独立思考，所以成长相对较慢。
有疑问的时候，先自己做个判断。不管判断正确与否，经过一次反思，你对系统的认识会更上一层楼。
如果是我该怎么办？
在熟悉系统的过程中，可以多提问。设计这个项目或者实现这个功能，应该怎么做？
原来的项目由于历史原因可能没有以最好的方式实现，通过对比我们预期的做法，我们可以很快理解系统这样做的深层原因。
通过一次又一次的自问，可以更快的了解系统的深层背景，同时增加自己的设计能力。
而且你原有的技能可以更好的反馈到新的项目中。
了解各种大中型项目的演变，有助于你真正了解一个项目。
淘系科技-淘系建筑-家的愿望
本人在大中小项目工作多年，分享一些经验。
首先说说中大型项目是如何演变的。
一些中型和大型项目进展缓慢。这些项目通常是从小项目或相对简单的架构发展而来的。随着需求的叠加或者目前的架构已经无法支持用户规模的逐渐演进。
一般演进方向是从单体-> SOA->微服务->云原生。
由于这类项目时间周期长，迭代多，需求文档和设计文档普遍缺失，文档普遍滞后于实施。而且这类项目一般都有一些漏洞或者历史包袱，很难通过文献直接了解项目。
其他中大型项目都是近期设计开发，周期较短，一般在两年内。因为这些项目都是近期设计的，业务或结构都比较复杂，所以在开发前都经过了比较完整严格的需求评审和技术选择/评审，存放的文档和线上代码一般不会有太大的差距。
因为在设计之初就定位为中大型项目，所以一般在开发之前的一开始就想好了需求和设计。初期功能上线后，后续的迭代升级一般不会做大的技术改动。一般是按照需求文档分阶段上线功能，或者修复一些小问题。因此，这类项目一般可以通过文档化来进行整体控制。
当然，我们愿意接触的项目都是后者，但往往一切都不顺利。那么如何才能快速切入前者的项目，相对缺少文档呢？
先说一下如何快速熟悉一个项目。
首先要了解业务背景。大多数情况下，技术服务于业务，业务优先于技术。一般来说，我们可以认为商业是一种商业模式。了解业务背景其实就是了解这个业务背后的运营模式，基于运营模式去深入。事实上，我变相地了解了整个系统。
比如我们接手一个推送消息系统，我们需要知道推送是什么，以及它的运行模式。什么是推？
推送可以简单的认为是一种触发用户的方式。我们通过推送到达终端设备，从而起到通知提醒的作用。一般来说，Push指的是无线设备上的应用通知。
Push的运营模式是什么？整个环节是什么样的？
我抽象了Push的整个环节:消息请求->消息接受->消息发送->消息到达->消息曝光->消息点击->后续业务转换，部分环节可以合并。
把整个推送环节抽象出来之后，我们就可以更深入的了解每个环节了。例如，如果我们想知道消息是如何发送的，我们会问消息是如何发送的。发给谁？
在App推送下，消息传递一般是指传递到特定的渠道，那么是如何传递的呢？
接下来我们来了解一下各个渠道是如何提供服务的，基于什么技术，需要如何使用，从而了解渠道投放的一般原理。
其实整个思路也是遵循总分总分的模式。我们先了解项目的整体业务背景和整体运营模式，然后基于运营模式中的每一点进行深入了解，再对每一点进行总结，最终达到对整个项目有一个整体认知的地步。
运营模式实际上是业务的抽象。如果你接手的项目没有直接的文档，其实可以使用相关的功能或者咨询相关的产品/运营同学了解一下，然后自己总结验证。整个过程结束后，你会对项目是做什么的，用户是谁有一定的了解。然后我们可以讨论如何开始。
了解了项目的运作模式后，我们如何入门写代码？
我们不是一上来就一行一行的读源代码，这样不仅效率低，还容易被细节缠住，把自己搞糊涂。那么我们该怎么办呢？
首先需要提前了解公司的常用技术，比如开发部署环境，常用中间件，DB等。，对公司的技术有一个大概的了解，和市面上的同类技术进行比较，知道每种技术的优缺点，这样我们就可以知道后面为什么要用这种技术。
其次，我们需要找出整个项目的重点和难点在哪里。对于一个有一定开发经验的同学来说，在我们了解了项目的运作模式之后，就可以去思考如何让你设计和实现整个项目，你会做什么，技术类型如何选择，哪里可能设计难度大，哪里可能有挑战。
在想清楚这个问题后，我们将验证当前项目的技术架构是否与预期一致。如果有不一致的地方，我们会找出原因，以及如何获取项目的技术架构。
该项目由各种应用程序组成，每个应用程序都有自己的模块。每个应用程序的职责一般很容易获得。应用的描述一般可以在公司内部找到，但是如何获得自己的模块划分呢？
如果有相关文件，当然好办，但是如果没有文件，可以试着让同事去了解一下。如果以上措施都不好用，只有代码可用，那就只能从代码入手了。
好的设计可以直接从项目的目录结构中知道应用模块的分类，从命名中知道模块的一般功能。其次，可以初步了解pom文件、打包脚本、接口类等提供的应用模块和服务能力。同时，经过这一步，我们可以整理应用程序和应用程序内模块的功能，形成一个文档。这样，当我们需要实现一个需求或者修复一个Bug的时候，就可以很快知道这个功能可能需要涉及到哪些应用和模块。
最后进行实战。了解了项目的运作模式后，对项目的架构和技术有了初步的了解，就可以从一个小的需求入手，或者尝试修复一个小的bug。这就是我们需要推导细节的时候了。
在收到需求后，我们考虑所涉及的应用程序和模块，然后查看这些模块的当前实现，并了解相关的实现。如何才能理解他们？
有一些很好的做法，比如在项目本地构建完成后调试代码，了解每一步的处理和数据变化，从而全面掌握这个小模块或者功能点的实现。这样，你就可以在心中有数之后，愉快地开发小需求了。在调试几个更小的需求后，你会逐渐熟悉应用程序的细节。
强烈建议您在项目熟悉期间整理自己的数据。
淘大技术部-前端技术-阮英
在调到淘系一年的时候，借此机会讲了我是如何在technology stack落地一个全新的业务和项目的。
强烈建议在了解项目的过程中，把自己所知道的东西沉淀成材料，以便理清和巩固自己的理解，同时也有助于自己和他人的跟进。从粗到细的整个认识过程主要分为三步:
第一步是了解业务
在开始一个新项目之前，如果你不知道项目的业务，那么大致了解一下整体业务，以及新项目在整体业务中的位置，会帮助你更快的了解新项目。可以关注新项目相关的上下游业务。
在这个过程中，你可以制作:业务大图和整体业务流程图。
第二步:了解项目/产品
功能流程:首先通过试用项目对应的产品，建立项目功能和流程的初步概念。
技术架构:通过项目已有的设计数据，结合表格结构、关键功能代码、鹰眼调用链信息等，了解新项目的技术架构。
该流程可以生成:项目业务流程图、系统架构图、数据模型和关键逻辑流程图。
步骤3:了解技术堆栈
如果新项目和之前的项目在技术栈上完全不同，那么你还需要了解新项目所在的技术生态。开发一个小功能了解和熟悉新项目的项目风格和技术产品就好了。
从小的需求开始，试着编码，逐步改正。
淘技术部-前端技术-正期
我总结一下自己的经验。大概有以下几个步骤。让我简单分享一下:
第一步是了解项目架构，根据服务划分模块。
接手一个新项目，首先要了解项目结构；后端大部分是按服务划分模块的，所以我们把项目按服务划分模块。
对于一般项目，已经有完善的项目文档，可以快速了解项目的主要模块，形成大致印象。
每个模块通常对应一个git存储库代码。这时候就必须记录下对应关系，这样在给定某个需求的时候，就可以知道具体的功能是在哪个存储库中实现的。
在这个过程中，不仅要看，还要手写笔记，要么画流程图，要么记录文档。不然很容易看一眼就忘了。
第二步:找到核心业务链接，将模块串在一起，并阅读代码。
核心业务环节是什么？核心服务链接是指系统提供的主要服务的代码调用链接。
为什么选择核心业务环节研究？因为核心业务一般是在核心模块之间调用，所以研究完之后我们可以很快对核心模块有更深入的了解。
以手机中间站为例，核心是将手机的屏幕数据以视频流的形式传输到页面端显示，涉及到
由会话服务器模块提供的会话服务；用户得到会话后，websocket直接连接到设备代理模块；设备的屏幕数据流采集和p64视频编码；网页侧的播放器模块实现播放；
看完这些模块，我基本上对手机的核心模块有了一个大概的了解。
同样，这个过程也需要画一个流程图来加深印象。
第三步:从小的需求开始，尝试编码。
我们很容易陷入一个误区，就是觉得对项目还不了解，不急着提要求。
其实我一直在看但没有做，只是印象不深。为学习而学习总是收效甚微；相反，带着具体问题去看，一步一步踩坑，才能快速上手；因为有些问题只有我们去做了才会被发现，比如代码规范问题，而如果我们不去写，就永远不知道我们离规范还有多远。这是一个逐渐修正的过程。
一开始的小要求不一定要快，主要以规范为主。之后有成就感，对我们来说也是正向激励。
摘要
正所谓“磨刀不误砍柴工”，淘工程师建议你从项目的本质出发，了解项目背后的业务，然后分析商业模式，并与应用实现进行对比。最后，在你熟悉项目后，通过完成需求，进一步实现业务，主动总结和沉淀自己的理解内容和数据文档。
原文链接:http://click.aliyun.com/m/1000298517/
本文为阿里云原创内容，未经允许不得转载。
