项目好与不好，它就在那里；架构优雅或者丑陋，它就在那里；注释有或者没有，它还在那里；文档乱或者不乱，它始终都在那里。不论它是什么样子的，线上就那样跑着。
一般来讲，项目分为两种：
1、为业务服务的项目，比如公司内部项目、电商项目、各种 app 项目；
2、为技术服务的项目，比如开源中间件项目（dubbo、spring cloud、各种数据库中间件、各种缓存方案等）；
首先说第二种项目，它专注于提供某一个或几个特定的功能。相对来说，这种项目技术实现上可能需要对这一领域有比较深的要求，但职责单一，目标明确。而且这种项目都是面向开发人员的，所以设计文档、接口文档、使用文档都会比较齐全。而且这种项目一般都会承担比较核心、比较重要的功能，并且还会在公司内部开放，甚至直接开源到社区。所以要经得起考验，代码都会写的比较规整。
开放出去，如果架构和代码不规整，就不会有人在 github 上 star，也不会有多少人使用。没人用事小，被人骂事大，让团队和公司丢脸更了不得了。所以这种项目比较容易接手，因为在文档和代码都比较规整的情况下，只需要在技术上下功夫就可以了。
本来项目应该有齐备的文档的，而现实中的好多项目往往不是这样的。由于各种各样的原因，比如框架比较老，人员变动，业务变动等，可能造成项目结构变的比较混乱。那么当我们应该如何快速的接手这样一个项目呢。
1、首先需要了解项目的的表现形式，什么是表现形式呢，就是说这个项目是提供 web 端服务，还是提供 App 端服务，还是其他形式的服务，又或者是混合了多种形式。我们比较容易理解具体的东西，而对于抽象的事物理解起来有一定的难度。所以看到项目最终的表现形式，可以对应到我们的项目结构中，这样一来，对于理解项目就比较容易了。
2、了解项目的部署架构。部署架构包括从客户端一直到数据访问层。这其中包括服务器系统版本，后端服务器软件类型（tomcat 、jetty 等），负载均衡配置，配置了多少台，用的是 nginx 还是 HA ,有或者是其他的。前后端交互方式，缓存是用到什么方案，是 redis 还是其他的，单机主备还是集群方案。数据库用的什么，有没有集群，有没有异地。数据库中间件用的什么框架等等。这个时候，最好有部署架构图拿来看一眼，如果是比较复杂的项目，肯定开发和运维会有部署文档的。如果没有完备的文档，建议要了解清楚之后，自己手动画一下部署架构图。
3、了解项目的代码架构。其中包括项目使用的基础框架，比如是 Spring mvc ，还是 Spring boot ，又或者是其他的框架，有没有用到 Netty 等其他的比较大的框架。有没有用到分布式 SOA 或者是否使用了微服务。用到分布式方案是 dubbo 还是 spring boot ，其中重点关注这些框架所用的版本，有些框架的版本可能比较老旧。
4、了解项目功能模块。到这里就和业务有关了，功能模块的划分一般和业务有关，比如注册登录模块、用户管理模块、订单管理模块、财务相关的服务模块等等。以及模块之间的依赖关系，是不是存在项目引用，是不是存在 RPC 调用或 http 服务调用关系等。这个时候，最好有完整的模块或服务依赖结构图，如果没有，最好在了解了项目结构之后，自己手动画一张。
5、最后，就是要理解具体的业务了，然后根据业务查看、调式对应的代码以及数据结构。
总体上要遵循从整体到细节，从高纬到低维的一个过程。如果能做好以下几点就最好了：
1、如果项目不是很复杂，最好可以有测试环境或者本地环境搭建起完整的项目架构。
2、如果项目很复杂，至少要保证自己负责的部分可以通过一些方法能在本地搭起来。
3、如果要在项目上做功能扩展，要遵循团队或项目的规范，不要独树一帜，这样会给后期维护带来麻烦。
4、修改功能之后，要维护好对应的文档。
想到哪儿写到哪儿，好多东西没写到位。
微信公众号，多谢关注：
还可以加入 Java 微信讨论群（如果二维码过期：请加微信:fengdezitai001 ,备注：cnblogs）：
