运用思考框架
- Where are we?（我们现在在哪？）
- Where are we going?（我们要到哪儿去？）
- How can we get there?（我们如何到达那里？）
先来看第一个问题，如果刚刚加入一家公司，哪怕我们不是一脸懵，也只是对公司业务有一个简单地了解，这是我们的现状。第二个问题来看看我们的目标。一般来说，我们都是打算在新公司大展身手，但这个答案太宽泛了，我们还需要进一步细化。在这个公司长远的发展是以后的事，我们还是把第一步的目标制定成能够达到上手工作的程度，比如，能够解决日常的项目问题。
所以最重要是解决第三个问题，我们可以将其分解为三个目标
- 业务
- 技术
- 团队运作
业务
来了一家公司，需要知道这个业务是做什么的，解决什么样的问题，具体的业务流程是什么样的等等，你可以请你的直属领导或者同事来和你讲解下公司产品业务，但是经常会出现很多人是分不清业务和技术的，经常把二者混在一起讲。但是你的目的只是想知道业务框架，并不是需要知道细节，所以我建议你大概了解情况后，后续可以找产品或者测试去谈谈,然后对比相关的需求文档，这时你会发现收货更多。
技术
技术这块，第一个要了解的肯定是开发语言了，这个不用多说，肯定是符合岗位要求的。一般都是先了解系统的业务架构，与哪些外部系统有交互等等。最好能够有一张或几张图将架构展现出来。现实情况是，不少项目并没有现成的图，那就大家一起讨论，在白板上一起画一张出来，之后再来慢慢整理。
有了一个初步的体系，接下来，就可以稍微深入一些。比如对外系统需要考虑的两点：
- 这个系统对外提供哪些接口，这对应着系统提供的能力
- 这个系统需要集成哪些外部系统，对应着它需要哪些支持
一旦涉及到与外部打交道，就涉及到外部接口是什么样子的，比如，使用REST接口还是RPC，亦或是MQ等等。
了解内部系统也要从业务入手，对应起来就是，这个系统由哪些模块组成，每个模块承担怎样的职责。如果系统已经是微服务，每个服务应该是一个独立的模块。
通常这也是一个发现问题的点，很多系统的模块划分常常是职责不清的，因此会产生严重的依赖问题，所以需要限界上下文，如果你觉得设计不合理，可以提出来，同事也觉得你经验不错，后续可以提建议优化。
业务之后是技术，对应着我需要了解分层。了解一个模块内部分了多少个层，每个层的职责是什么。了解了这些对系统的设计，也就对系统有了一个整体的认识。
最后就是代码层面了，代码的目录结构，使用框架，中间件等等，可以尝试启动项目本地调试一遍。
团队运作
团队运作我需要知道需求是从哪来的，产品最终会由谁使用，团队需要向谁汇报。如果有外部客户，日常沟通是怎么安排的。
再来就是内部的活动，一方面是定期的活动，比如，站会、产品研发流程各个节点会议、周会，这些不同活动的时间安排是怎样的；另一方面是团队的日常活动，比如，是否有每天的代码评审、是否有内部的分享机制、团建活动之类的等等。
通过了解这些内容，基本上可以大致判断出一个团队的专业程度，也可以知道自己需要帮助的时候，可以找谁帮忙，为自己更好地融入团队打下基础。
附赠一点小技巧：使用“行话”。在交流的过程中，学习一点”行话“。这会让人觉得你懂行，让你很快得到信任，尽早融入团队。
——读自极客时间
