入职新公司，快速掌握业务与技术的12条经验

一、背景

最近，看到有人想了解；

刚找到工作，怎么才能在试用期或者入职后，快速掌握部门和公司的业务和技术呢？

对于这个问题，我也一直在持续思考这个问题，最近我总结了一些方法论和经验，希望能对大家有所帮助。

先来喝一碗鸡汤，润润喉咙，让鸡汤点醒你:

鸡蛋从外打破是食物，从内打破是生命。

人生从外打破是压力，从内打破是成长。

如果你等待着别人从外打破你，那么你注定成为别人的食物。

如果你自己从内打破，那么你会发现自己的成长相当是一种重生。

一个人想要改变自己的命运，靠的不是别人，关键在自己。生命的真谛就是，自己做自己的摆渡人。

最近，我根据自身的过往经验，总结了12条经验分享给你：

二、工作产出方面

经验与建议1：日常总结与输出

建议大家前期每天都进行工作总结，并整理成文章或文档。我觉得这个至少要坚持1-6个月，直到试用期通过，或者自己感觉已经获得了公司同事的信任后。你可以记录公司的各种访问环境、当前项目所用到的技术、你每天的所见所闻，或实际遇到的问题。

要沉淀下来眼睛可以看到的资料和文件，逐渐形成自己的知识库和文档。通过这样的沉淀和积累，不仅能帮助你更好地掌握部门业务和技术，还能为你的职业发展打下坚实的基础。如果当前公司没有创建相关的知识库或者部署知识库软件，我强烈建议你在公司创建一个知识库，从自己开始，梳理知识，本质也是一个PKM管理的过程。目前常见的知识库软件包括：Confluence、飞书、钉钉、语雀等都是可以的。这个积累的文档，也是后续自己可以在公司和团队内容持续分享的内容。

我是建议前期每周至少要输出3-5篇总结，遇到不懂的问题时，可以携带自己的梳理结果去问Mentor或Leader，这样沟通起来会更加高效。而不是自己啥都没有准备，直接去问。这也是提高双方沟通和协作效率。如果担心同事不给你回复，尝试用如下的套路话术进行处理：

我遇到了一个问题或场景：【问题描述】，我想要实现【X功能】，但是出现了【Y现象】，我经过以下尝试：【思路细节】，但是不能解决，报错如下：【报错信息或截图】，或者我使用【关键词】百度，但是找不到答案，请问我该怎么解决或分析。

怎么提问也是门需要学习的内容，开源世界有个标星29K的开源项目：提问的智慧。

建议阅读一下，项目地址：github.com/ryanhanwu/H…

如果你是个内向的人，担心自己的工作，可以先看看我之前的这篇文章：

经验与建议2：问题复盘与记录

对于自己在企业中的工作，我希望你可以做到这种事：当你在工作中遇到项目组线上问题或某个实际已经发生的系统问题时，无论自己是否是是该问题解决人，都应该立即在电脑上创建一个文件夹来记录问题。 例如:

20240408-内网测试环境磁盘空间占满导致的业务系统无法访问问题

20240410-生产环境出现问题重复发货问题

20240423-生产环境某用户IP持续攻击系统

20240423-业务操作数据时出现重复插入问题

。。。

待同事或者自己解决后，在该文件夹中创建一个txt文件至少来描述内容，也可以附上截图。 问题解决后，可以自己主动及时进行复盘和总结，描述的内容包括：错误提示或现象或截图是什么，怎么出现的，怎么解决的，解决的步骤是什么，如何防止问题，怎么优化处理这个问题。 要坚持做这样的事。我相信没多久你就发现自己积累了不少问题处理经验，这个积累的东西也是自己的财富，不过这种这种个人建议是那种实际的问题，而不是工作中遇到的开发的小问题，工作中的开发问题可以像往常一样记录到笔记或其他地方。

这个记录的价值是非常大的，企业中不是所有人的记忆力是好的，你前期说过的话，做过的事，没有多少人会刻意的记住，比如你刚入职说你是XXX大学毕业的，我相信未来的某个时间很多人都忘记了，可能还会问你。那么对于程序员职业中的软件开发问题也是如此，如果你能将历史的问题进行自己总结和沉淀，那么在将来你就非常容易的、非常清晰的把事情在重新描述一遍，同时在潜意识中，你也会越来越深刻。

未来答辩时候也会有证据沉淀下来，作为答辩的数据支撑。同时也是当领导忘记某个现象的时候，自己可以非常清晰的说出来这个东西的产生的背景、解决思路等。AI大火之后，我们完全可以让AI来帮你学习和解释你的这个问题，同时还能系统化、结构化沉淀。

三、项目学习方面

经验与建议3：环境搭建与熟悉

当你接收到项目源码后，大部分情况下，首先要做的就收集和搭建公司相关的开发环境。

搭建本地开发环境并成功启动项目是大多数人经常入职后会做的工作。此时公司可能会给你提供文档，也可能没有给你提供文档，那么这个时候我个人的建议是不管是否提供了文档，我都建议你基于自己的环境边做边截图记录文档，按照自己的思维和操作步骤重新记录一份操作过程文档，这个同时也是在梳理更新原有的操作步骤。未来要是有其他人入职，自己的操作过程就是为公司提效的一个方法，其实，慢慢的你会发现，有些时候你把同事的效能提升了，自己的研发效能也会提升。

然后，你可以继续梳理，可以尝试使用开源的dbchm工具或screw工具来生成数据库文档结构，并针对你感兴趣的表进行熟悉。这是了解项目数据结构和业务逻辑的重要步骤。一定要做呀，兄弟。好多人来项目组很长时间了，表啥的都不清楚。

screw的项目地址：gitee.com/leshalv/scr…

dbchm的项目地址：gitee.com/dotnetchina…

screw导出的数据库文档截图1:

截图2：

除了数据库的环境梳理之外，在实际的企业公司中，我们的软件写完后，会在不同的环境上进行测试，直到发布到生产环境，各个环境的含义如下：

1. DEV开发环境（Development Environment）：

   • 这是程序员们专门用于开发的服务器。
   • 配置可以相对随意，为了方便开发调试，一般会存在各种测试的假数据。
   • 主要用于编写和测试软件的代码和功能。

2. SIT集成测试环境（System Integration Testing Environment）：

   • SIT是系统集成测试的缩写。
   • 用于在软件开发周期的早期阶段验证系统中不同模块之间的集成和交互是否正常工作。
   • SIT环境通常用于开发团队内部进行测试，模拟真实的生产环境并与其他系统集成，但通常不包含最终用户数据，不过大多数公司都是开发环境是一套，资源配置不高。

3. UAT验收测试环境（User Acceptance Testing Environment）：

   • 这是在软件开发过程中，为了验证软件功能是否满足用户需求，而模拟实际用户操作环境所搭建的测试环境。
   • 通常包含了开发环境、测试环境和生产环境的一部分特性，但独立于生产环境。
   • 在UAT环境中，软件会经过业务用户的实际使用和反馈，以确保软件在正式投入生产环境之前，能够达到预期的功能和性能要求。有些时候会从生产环境上同步和导出部分数据，来模拟实际的情况进行测试

4. GRAY灰度测试环境（Gray Testing Environment）：

   • 灰度测试是指在新功能或重大改版即将推出时，首先进行小范围的尝试工作，然后逐渐扩大范围，直到新功能覆盖到所有系统用户。
   • 灰度环境就是用于这种小范围尝试的测试环境。
   • 通过灰度测试，可以收集用户的反馈并及时修复潜在问题，以确保新功能在全面推广之前已经得到充分的验证和优化。在以前做项目的时候，我们只灰度了应用服务器，灰度的应用服务器和生产环境共享同一个DB。

5. 生产环境（Production Environment）：

   • 这是指正式提供对外服务的环境。
   • 生产环境包含了所有的功能，任何项目所使用的环境都以这个为基础然后根据客户的个性化需求来做调整或修改。
   • 在生产环境中，软件会接受大量用户的真实使用，因此需要保证高度的稳定性和可靠性。

以上这些环境共同构成了软件开发生命周期中不同阶段的关键组成部分，确保了软件从开发到上线的整个过程中都能够得到充分的测试和优化。

经验与建议4：项目依赖梳理

自己主动尝试下分析并整理项目中的pom.xml文件，了解项目都依赖了哪些库和框架，都设置了什么。自己做个整理，这个步骤能帮你快速掌握项目所用的技术栈和关键组件。同时也可以去掉某些依赖，看看哪些类在编译的过程中出现了错误，可以顺便熟悉下某些操作的类。

经验与建议5：尝试实战练习

不管第1周，是否被安排了工作，我希望你在熟悉环境的基础上，尝试开发一个简单的CRUD功能，可以是2-8个字段的小功能，如果不知道，就打开系统，找到你认为最简单的一个功能进行模仿。这不仅能快速提升你的公司项目的实战能力，还能加深你对项目的理解。记住，不要只是被动地接受任务，而要主动地学习和实践。 这个是非常重要的、这个是非常重要的、这个是非常重要的 很多人到公司都不自己搞这个练习，而是被领导牵着鼻子走，领导让熟悉项目，自己就仅仅熟悉而已，对于自己的工作丝毫没有产出。自己上了半个多月班了，领导一直没有给安排开发任务，就是让你看代码，熟悉系统，也没人给你讲业务啥的，你就一直待着那像话吗。当你工作多年后，你会发现一个新入职的主动沟通的人更重要。

经验与建议6：主动代码质量分析

自己可以利用阿里巴巴代码扫描工具或sonarlint工具来扫描项目中的代码质量问题。通过了解当前项目的代码风格和潜在问题，你可以更好地融入团队并提升代码质量。这个非常有助于你知道当前项目的问题可能在哪里，好多人经常说不熟悉公司代码，其中一个原因就是他们就没有尝试分析过，对项目代码没有个全貌。不管代码是好是坏，我都建议你想办法去梳理和总结当前代码有哪些缺陷和优化方向。

四、业务熟悉方面

经验与建议7：全流程业务梳理

选择一个你认为比较简单的界面或功能，从前端设计、浏览器控制台访问的路径、请求参数、响应数据、后台接口到数据库设计等方面去梳理业务流程。这个过程中，你可以沉淀一份详细的文档，以便后续查阅和参考。能让别人知道自己的主动能力，同时这也是很多人入职公司后，没有主动去做的事，有些人入职很久后，有些常见的功能还是不知道如何交互的。对于这块的梳理，可以用流程图、或者时序图画，也可以使用基于Mermaid那种代码生图的功能去画。

经验与建议8：积极沟通与融入

利用午餐时间或其他合适的时机，与Mentor或Leader在吃饭的时候进行沟通交流。或同事在抽烟的时候，自己也可以一起去放松下。你可以聊聊当前职位的安排、后续工作的计划以及自己的过往经历等。这样不仅能增进彼此的了解，还能展现你的沟通能力和团队协作精神。这个非常重要，能让别人知道自己的沟通能力。

经验与建议9：主动了解与参与业务

需要清楚当前项目组的项目经理和产品经理是谁，平常大概会负责哪些内容，同时建议你主动查阅相关的需求文档或即将进行的需求开发。通过了解历史与即将进行的需求，你可以更好地把握业务方向和发展趋势。针对过去某个需求的需求文档或即将做的需求文档，自己先去看，去主动的问，这个是最最重要的，要自己主动去找别人要，或者在飞书中可以看到历史的文档，这样就可以在后续的中午吃饭的过程聊聊自己看过的东西，比如：某天中午吃饭的时候，可以和leader说：唉，我看咱们之前做过一个xxx功能，一个xxx的业务，那个东西xxx怎么样啥的，感觉xxx的。

这个阶段多数的公司会让你基于目前的需求进行工时分析，确定自己多少天内完成，常见的就是告诉别人多少人天，多少小时，如果自己无法预估出来，可以先尝试从接口维度、页面数量、交互操作方面先拆出来明显的内容，然后再逐步细化。

虽然我这么说了，但是对于那些初出茅庐，初入职场的小伙伴，还是缺乏估算工时的经验，对于这种情况，还是建议找公司的同事协助帮忙估算，待有了一定的感觉后，可以尝试开始估算一下，估算的时候，不要只考虑开发的时间，要附加上：

技术预研的时间、设计思考的时间、真正写代码的时候、研发自测的时间、前后端联调的时间

比如要求你实现一个登录的功能，你感觉写代码很容易，自己只估算了4个小时，但是最后自己却花费了2人天。这里之外一定要想想自己是否会产生技术预研的时间、设计整理思考的时间、研发自测的时间等。在纯开发的基础之上，增加和冗余出来一点时间。对于任务的执行结果和完成目标最好也定时且积极的与组长进行沟通确认，别想着工作自己觉得做完了，就开始持续摸鱼了，然后下班的时候才通知组长完成了任务。摸鱼几分钟来休息休息也是没啥问题的。

对于积极主动也是高效能人士的七个习惯之一：

积极主动的了解业务的另外一个思路就是自己去看下业界同类软件产品是如何实现的、如何进行产品设计的，比如人人都是产品经理这种网站等，然后这种网站上都会更佳细致的给你讲解某些业务需求的设计思路，虽然可能和公司的产品设计相比有不同之处，但是如果你能看明白，你就具备了一定的业务需求的理解和认知能力，能够和别人谈谈需求相关的周边知识。在企业工作中，如果你仔细发现观察身边的同事，有些程序员刚入行时的开发状态真的是不管业务的，业务需求的界面上没描述的东西，不会主动的去发现和沟通，需求没落实到具体的文字描述上，就不思考了。往往在测试阶段会暴露出来某某方面的细节控制没处理，产生多余的测试时间。所以在企业中，主动沟通和主动思考是非常重要的。

经验与建议10：态度

如果入职当天或当周或当月，项目组存在加班的情况，在初入职场时，建议不要过早离开。可以适当的和项目人员共患难一下，你可以在工位上偷偷学习或参与团队讨论，以展现你的职业态度和团队协作精神。哪怕是在工位上学习也要装着，和同事一起下班，下班时候又可以聊聊公司、聊聊技术、吐槽吐槽，潜意识在告诉同事你的态度。对这种事不认可的可以忽略这条，也不要攻击和说我。如果你觉得自己工作无法按时完成时，你还早早下班，我觉得就不太合适了，殊不知你的这个小小细节，可能就会带来同事对你的态度认知，及时你不加班，我也建议你在身边同事走了后你在走，别让他们看到你在他们之前走。

经验与建议11：日常积极参与技术讨论

如果群里有技术问题讨论，我希望你可以积极参与并分享自己的观点和经验。这样不仅能提升你的技术影响力，还能更好地融入技术团队。或者你抛出一个你认为能解决当前业务问题的技术视频或技术博客或原型设计，别人看不看不重要，重要的是让别人知道，遇到问题时，你分享了自己的思路和看过的资料，给同事了一点思路和方向，你能一击必中的找到资料和答案。对于积极讨论，最容易参与的一个环境就是需求分析，如果你在需求分析中一直不说话，其实是有问题的，你可以给自己定个小目标，每次需求分析时，至少在需求会议沟通中提问3个问题。本质上讲解新需求的时候，大家都是0，既然如此，有啥害怕的。不懂就是不懂。你不说反而让上级担心。你如果理解了当前需求的目标用户是谁、当前需求解决了什么业务痛点等等，我相信在后续的开发过程中，你会发现更多需要考虑的细节问题。AI火了后，我们完全可以把需求给AI，你去问他，或者让他问你。

五、Mentor方面

经验与建议12：找到能指导你的Mentor

我觉得有些人之所以不知道如何快速熟悉公司的业务和技术的其中一个原因在于：

由于公司没考虑过新人指导或者流程不健全，大多数公司入职后是没有分配一个Mentor手把手指导的，导致很多人其实具备能力，但是缺乏目标和方向性的路线。大厂可能在这个方面更健全一点。

大部分公司实际情况更多的是，入职后希望你能尽快上手工作。

同时我告诉你：你的Leader不完全等于你的Mentor。有些Leader是不对你的个人成长负责的，他只是在管理你这个人。你可以逐渐的找到公司中你觉得适合当你Mentor的那个人，当然也有可能就是你的Leader.

我觉得一个Mentor对你的想法应该是怎么把你快速培养起来，然后替代自己做某些事。显然很多公司不会这么做，哪有时间指导你做每件事。你自己不会干就淘汰。

两者的区别：

leader通常指的是在某个组织或团队中担任领导职务的人，他们负责指导和管理团队，确保团队目标的实现。leader在团队中扮演着重要的角色，他们的决策和行动对团队的整体表现有着直接的影响。

而mentor则指的是导师、指导者或良师益友。这个词源自古希腊神话中的“门托尔”（Mentor），是智慧女神雅典娜的化身，也是奥德修斯的老师和朋友。mentor通常

被认为是一位具有专业知识和经验丰富的人，在某个领域对他人进行指导。

两者的表现：

Leader总是忙于协调各个英雄（团队成员）之间的合作，确保他们不会互相碰撞（代码冲突），还要确保每个英雄都有足够的能量（资源）来发挥他们的最大潜力。虽然Leader不会亲自写代码，但他总是知道哪个英雄（团队成员）最适合完成哪个任务。

Mentor则是那个坐在角落里，喝着咖啡，看似悠闲自在的“老鸟”。他手里总是拿着一本破旧的“编程秘籍”（其实就是他的笔记本），上面写满了各种神秘的代码和注释。每当有年轻的程序员遇到难题时，他都会微笑着走过去，用他那双深邃的眼睛扫一眼代码，然后轻描淡写地说：“哦，这个问题啊，其实你只需要在这个循环里加上一个条件判断就可以了。”

Mentor不仅会用他的智慧和经验帮助年轻的程序员解决问题，还会告诉他们一些编程的“黑科技”和“坑点”，让他们少走弯路。他还会分享自己当年如何熬夜写代码、如何与产品经理斗智斗勇的有趣故事，让年轻的程序员们既感到敬佩又觉得亲切。

六、最后

如果你能做到，我说的上面的这几点，我非常有理由相信你可以打败部分比自己早入职的一些同事，同时熟悉度也会比他们高出不少，上手也会快。这个是真事。一个程序员在工作中，有些时候不是看能力，而是看工时/效率/解决问题的能力。

以上就是我关于如何快速掌握部门业务和技术栈的经验分享。

希望大家能够结合实际情况灵活运用这些方法论和经验来提升自己的职业素养和综合能力。同时我们也要明确一点：

虽然这些经验和方法论具有一定的普适性但每个人的情况都是独特的因此我们需要根据自己的实际情况进行调整和创新，最后祝大家能够快速成长和进步！

喜欢本文的，可以关注、收藏、点赞、转发、分享到朋友圈哦。