码农：如何快速融入团队

问题：码农如何快速融入团队？

记住一个标准：能干事、能抗事。

总结一个字：靠谱。

适用范围：新手码农、老司机码农、测试、DBA、运维、产品经理、项目经理、架构师、技术专家、。。。。适用于任何行业的打工者。

下面要做的事情，其实就是为了让你符合标准“靠谱”。

一、搭环境

1.把开发环境搭起来，不懂就问（问老员工），比自己一个人折腾，效率高。

2.熟悉开发流程：梳理好你的上下游。表象是“需求评审”、“技术设计评审”、“测试用例评审”

上游：产品经理、项目经理、项目中服务依赖方（给你提供服务接口的大佬）、你所在业务功能的架构设计者（架构师、技术专家）。

下游：测试、前端大佬、项目中服务依赖方（调用你提供服务接口的大佬）。

其他：运维大佬、DBA大佬、技术专家、架构师。这些是能给你提供帮助的大佬。

直属上级：你的领导、你的领导的领导、你的领导的领导的领导。有些跨部门、跨小组的资源协调，你需要得到他们的助力。

配置管理工程师（可选）：一般稍微大点的公司，会有专门的版本管理工程师，要由他们给你开git账号、权限。很多时候jenkins，CI/CD都在他们手里。

二、翻文档、理解产品

在git/svn资料库找文档：需求文档、产品文档、测试用例文档、软件设计文档、数据库设计文档、运维文档等等。可以先从产品文档入手，从用户角度去学习和理解产品，然后就是数据库设计文档、软件设计文档。

看完文档、做好笔记，梳理业务主线、梳理你所负责部分的表间关系、数据流程、功能调用流程。

三、熟悉产品、深入理解业务。

1.跑工程：

完成搭环境、翻文档后，对产品有了初步认识，就可以拉取项目源码，在本地把工程跑起来，按照产品说明书，把业务主线操作一把，或者把你负责的功能跑一把。

2.看文档：

再把需求文档、产品文档、测试用例文档、软件设计文档、数据库设计文档翻一遍，结合本地环境，整体再过一遍，毕竟看文档总是比看代码快！

3.看代码：

按照业务主线，debug一遍代码，加深理解当前代码结构、工程结构、软件设计架构，表间关系。这个时候记得多多请教老司机（老员工、测试大佬、运维大佬、dba大佬、架构师大佬、技术专家大佬），这样效率高。结合历史文档，消化理解与自己相关的功能模块。

4.想清楚再动手：

分配给你的任务，不要立马写代码，提交代码。先给出你的设计方案，主动找上级或者老员工评估你的设计思路，没啥问题了再动手。

避免出现，你提交的代码被回退或者撤销，在codereview时被否掉的代码，非常浪费时间和精力，记住“代码被打回”是“不靠谱”的表现。

四、注意事项

1. 深入核心，掌握业务流程

首先，你需要快速了解并掌握新系统的核心业务流程。这包括了解系统的整体架构、主要功能以及关键的业务流程。通过深入了解，你能够更快地把握系统的核心价值和用户需求。

2. 全面遍历，熟悉系统功能

在掌握核心业务流程的基础上，你需要全面遍历系统功能。通过实际操作和测试，熟悉系统的各项功能和操作流程。这有助于你更好地理解系统的运作机制和用户体验，为后续的优化和改进打下基础。

3. 承接优化，参与运维工作

在熟悉系统功能的同时，你可以主动承接一些优化需求和部分运维工作。通过参与实际的工作流程，你能够更深入地了解系统的运行情况和潜在问题。同时，这也是一个学习和提升的好机会，能够让你更快地掌握相关技能和知识。

4. 自上而下，分析系统结构

除了熟悉系统功能外，你还需要从系统的整体结构出发，自上而下地分析系统。通过了解系统的技术架构、数据流向以及模块间的交互关系，你能够更全面地理解系统的运作原理。这有助于你更好地进行系统优化和升级工作。

5. 升级重构，提升系统性能

随着业务的发展和技术的进步，你可能需要对系统进行升级或重构。在这个过程中，你需要根据业务需求和技术发展趋势，制定合理的升级方案和技术路线。通过升级重构，你能够提升系统的性能和稳定性，为用户带来更好的体验。

6. 按需优化，持续改进

最后，你需要根据用户的反馈和业务需求，持续对系统进行优化和改进。通过收集和分析用户数据、关注行业动态和技术趋势等方式，你可以不断发现系统存在的问题和潜在的需求点。通过按需优化和持续改进，你能够不断提升系统的竞争力和用户体验。

7. 做笔记和问同事：

做笔记就是自己消化的过程。问同事的问题，记录好，多画图（脑图、流程图、时序图、用例图），写清楚每个步骤，能记录有多细，就记录多细。小到功能截图、代码截图、备注。

脑图梳理功能

时序图梳理上下游调用链

功能流程图梳理业务逻辑

8.复盘：工作小结（题外话）

当前工作情况，找自己的问题，解决思路。

1、找到自己的定位（情商很重要）

首先要明确的清楚自己解决的到底是什么问题。例如项目端，除了大型项目，普遍没什么技术含量，都在解决业务问题。在这个领域的小伙伴，要思考的就是自己解决的是技术问题还是业务问题。如果解决的是业务问题，那么这个业务是不是可持续的？这个方向的小伙伴，建议就是业务和技术并重，不要把精力都放在技术上。

最好往大项目上靠，例如千万级或者上亿级，这样规模的项目，业务普遍相对复杂一些，能学到的东西更多。

我一个朋友，在某国字头企业做运维。因为服务态度好、嘴甜，最后得到了领导的认可和信赖，然后开了个公司，去年销售额做到了几千万。他并没有什么技术，他解决了更上层的问题，即：打通了销售渠道。

做业务行业的，建议就是多关注用户关系、业务，与之对应的技术方向，就是基于业务下的技术架构。那么为什么这个业务需要用这个架构做？

另外，其实很多IT公司，有个不可说的秘密。就是，其实这个公司是国家为了解决就业而产生的，你如果在这样的公司里，要注意的是和领导的关系。然后你需要思考公司是靠什么赚钱的，然后往相关的职务上靠。

再说产品端，做产品端比项目端要稳定很多。（大型项目除外，例如千万级或者亿级项目）产品端，普遍比较重要的事情是战略管理，也就是差异化和成本。要做差异化，普遍依赖于技术，因为没有技术也就没法形成技术壁垒。那么做这个核心的事情，就比较重要了。现在，大厂里，想做核心技术或者核心业务，也需要靠资源优势。怎么拿到资源才是你要解决的问题。