作者简介：李瑞岚，理财技术专家
很多技术人在换到新的工作环境、新的业务的时候，可能都会有一种迷茫。这种迷茫源于对未知领域的不了解，不知道该怎么做，怎样才能尽快上手。快速地熟悉业务项目，不但可以迅速投入工作，还可以提高自己的自信心，更好地在新团队业务中landing。下面我整理一些资料，从业务、技术、团队协作等方面，以及这么多年的工作经验，总结一些快速熟悉团队业务项目的技巧。
什么叫业务？
通俗点，业务就是团队所要做的事，要实现的目标。
业务就是团队所做的东西是怎么发展起来的，经历了什么，现状如何，未来趋势怎样。
举个例子，我们可以自己总结一下团队业务在公司的定位，服务的目标客户群体是谁，需要为他们带来什么价值。
为什么要了解业务？
技术驱动业务，同样也会由于业务的特殊需求而去反向推动技术。
了解业务，有时候可以对复杂的业务架构进行拆解，从而优化技术架构和实现方式。
了解业务，可以从一个上帝视角对整体业务进行总结和概括，明确业务未来的发展方向。
所以，了解业务就好比我们掌握了一张地图，指引着技术及未来的方向。这里为什么要先说业务？如果上来就直接撸代码，就极有可能将自己陷入一个漩涡之中，因为你根本不知道你看的这段代码背后的含义，为什么要这么写，它实现的是什么业务价值，这无形当中就把自己带进了一个黑洞，看得越多就会觉得越虚。
如何了解业务？
怎么做？
跑一下所属业务的流程，例如可以先浏览APP中相关的页面，完成一些交互，还有后台系统工具的使用。所有交互页面点点、浏览浏览，大概知道一个交互链路。
一般团队都有一些沉淀的文档，拿到这些文档首先可以对文档分类，哪些是业务介绍，哪些是系统设计。对文档进行分类阅读，可以提高文档的阅读效率。
登录需求系统，看一下团队的一些历史需求记录，帮助我们了解业务的进展及变化。
另外还有一些事件、事故的分析文档，这些分析文档可以帮助我们去了解一些更细节的业务信息，从而提升对业务的认识，避免在以后的工作中踩坑。
可以找谁？
TL、组长：TL和组长一般是对这块业务比较熟悉的人，可以对自己的业务疑惑进行解答。在平时接需求的时候，需要对自己做一个提问，这个需求的背景是什么？怎么做才能实现业务指标？从更深的一个层次对业务进行认知。
测试同学：测试同学作为质量这块的owner，也是一个对业务十分了解的人，在平时或者做需求的时候，可以和测试同学多沟通，也可以为自己解答业务的疑惑。从以往及现在的经验来看，测试同学对自己在业务这块的成长都起着比较大的作用。
技术
就如刚刚所说，技术驱动业务，技术也是了解业务的关键所在。
技术栈
在阅读项目需求和系统设计文档时，首先需要先了解工程用到了哪些技术栈，对于自己不熟悉的技术栈需要额外去补习。
项目架构
团队都会负责一些工程应用，这些工程应用主要职责是什么？哪些是纯后台应用？哪些是专门提供服务的？哪些是面对前端的？各个应用的依赖关系是怎么样的？域外的上下游应用都有哪些？理清了这些关系，可以对域内的一些系统做一些总结，方便后面设计出更合理的架构。
开发环境
是用什么进行代码管理的？用的什么开发语言？自动化构建工具是什么？用的什么部署环境？
表设计及数据库
系统的表设计是整个系统的核心，只有熟悉了表设计，才能对整个系统的功能有大致的了解。了解所使用的数据库，方便后续数据查询以及功能的开发。
业务代码
首先了解代码的一个分层情况，哪些是接口层，哪些是业务核心层，哪些是DAO层，Job入口在哪里？消息监听入口在哪里？对系统的接口做一个整理，可以根据业务进行划分，找准入口才能方便进行下一步的阅读。
事务型接口代码，可以抱着一些问题去进行阅读。这个接口是否需要满足幂等性，如果要满足幂等性，这个是怎么实现的？这个接口是本地型事务还是分布式事务，如果是分布式事务是如何保证的？这个接口并发了会变成什么情况？这个接口中途有事务提交失败是怎么处理，是整个接口返回失败还是会自己重试？带着这些问题去阅读可以进一步完善我们对系统架构设计的认识。
查询类接口代码，需要关注接口的缓存问题，这个接口查询有没有加缓存，是需要实时数据还是非实时数据？这个接口的缓存是在最后返回的时候加的，还是在接口二级查询的时候加的，二级查询的缓存不一致对接口的正确性有没有影响？这个接口的请求有没有一些机器的路由规则？万一缓存在各个服务器中存储不一致怎么办？接口的缓存时间为什么要设置这个值？
不管是事务型接口还是查询类接口，在阅读完代码后，都建议自己去debug一下接口，跟踪代码的请求路径，沉浸式地感受一下代码的走向和数据在表里的变化情况。
监控和日志
监控是发现问题的预警手段，日志是线上问题查询的关键，要了解怎么去设置监控和日志查询，方便解决生产问题。
除此意外，遇到线上生产问题自己可以去尝试查询，完成一个生产问题的查询相当于破解了一块拼图碎片，问题查得越多，到手的碎片也就越多，最终也能拼成一张大的业务拼图。
团队协作
最后，我们来说团队协作，了解团队协作可以方便对团队业务进行推动以及日常工作的处理。
我们的需求从哪而来，如何排期，如何交付，如何上线。
我们的产品团队、运营团队、前端、依赖的下游团队都有哪些，负责人是谁，方便日后的交流。
出现生产问题有没有一个规范的处理流程，需要怎么报备？
是否有值班机制，值班的任务是什么？
日常活动，是否有晨会、周会，活动是如何安排？是否有周期性的分享？是否有周报、月报？
团队的考核机制是什么？
俗话说，好记性不如烂笔头。在接触团队业务之初，不免有很多东西不熟悉，可以用文档去记录一下自己是怎么去解决的，这个不仅可以加深自己的印象，还可以作为文档沉淀，方便后续的同学查看，避免踩同样的坑。
同时要保持一颗开阔的心态，做任何事情都需要一个过程，切记心浮气躁，问题总归可以得到解决。
