公众号名称：无处不在的技术

作者名称：无处不在

发布时间：2024-05-11 13:49

0****1

背景

最近，看到有人想了解；

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

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

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

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

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

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

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

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

我总结了12条经验分享给你：

0****2

工作产出方面

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

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

要沉淀下来眼睛可以看到的资料和文件，逐渐形成自己的知识库和文档。通过这样的沉淀和积累，不仅能帮助你更好地掌握部门业务和技术，还能为你的职业发展打下坚实的基础。我是建议每周至少要输出3-5篇总结，遇到不懂的问题时，可以携带自己的梳理结果去问Mentor或Leader，这样沟通起来会更加高效。而不是自己啥都没有准备，直接去问。这也是提高双方沟通和协作效率。如果担心同事不给你回复，尝试用如下的套路话术进行处理：

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

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

单击访问：内向性格的开发同学，没有合适的工作方法是不行的

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

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

例如:
20240410-生产环境出现问题重复发货问题
20240423-生产环境某用户IP持续攻击系统
20240423-业务操作数据时出现重复插入问题
待同事或者自己解决后，在该文件夹中创建一个txt文件至少。

​也可以附上截图。​
问题解决后，可以自己主动及时进行复盘和总结，描述的内容包括：错误提示或现象或截图是什么，怎么出现的，怎么解决的，解决的步骤是什么，如何防止问题，怎么优化处理这个问题。​
要坚持做这样的事。​我相信没多久你就发现自己积累了不少问题处理经验，这个积累的东西也是自己的财富，不过这种这种个人建议是那种​实际的问题​

，而不是工作中遇到的开发的小问题，工作中的开发问题可以像往常一样记录到笔记或其他地方。
这个价值在于未来答辩时候有证据沉淀下来，作为答辩的数据。同时也是当领导忘记某个现象的时候，自己可以非常清晰的说出来这个东西的产生的背景、解决思路等。

0****3

**项目学习方面
**

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

当你接收到项目源码后，大部分情况下，首先要做的就是搭建本地开发环境并成功启动项目。​此时公司可能会给你提供文档，也可能没有给你提供文档，那么这个时候我个人的建议是不管是否提供了文档，我都建议你基于自己的环境边做边截图记录文档，按照自己的思维和操作步骤重新记录一份操作过程文档，这个同时也是在梳理更新原有的操作步骤。​未来要是有其他人入职，自己的操作过程就是为公司提效的一个方法，其实，慢慢的你会发现，有些时候你把同事的效能提升了，自己的研发效能也会提升。​
然后，你可以继续梳理，可以尝试使用开源的dbchm工具或screw工具来生成数据库文档结构，并针对你感兴趣的表进行熟悉。​这是了解项目数据结构和业务逻辑的重要步骤。​一定要做呀，兄弟。​好多人来项目组很长时间了，表啥的都不清楚。​****经验与建议4：****项目依赖梳理

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

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

不管第1周，是否被安排了工作，我希望你在熟悉环境的基础上，尝试开发一个简单的CRUD功能，可以是2-8个字段的小功能，如果不知道，就打开系统，找到你认为最简单的一个功能进行模仿。这不仅能快速提升你的公司项目的实战能力，还能加深你对项目的理解。记住，不要只是被动地接受任务，而要主动地学习和实践。
​这个是非常重要的、这个是非常重要的、这个是非常重要的​

很多人到公司都不自己搞这个练习，而是被领导牵着鼻子走，领导让熟悉项目，自己就仅仅熟悉而已，对于自己的工作丝毫没有产出。自己上了半个多月班了，领导一直没有给安排开发任务，就是让你看代码，熟悉系统，也没人给你讲业务啥的，你就一直待着那像话吗。当你工作多年后，你会发现一个新入职的主动沟通的人更重要。

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

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

0****4

业务熟悉方面

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

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

单击立即学习：强烈推荐:用Mermaid轻松绘制时序图，非常香

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

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

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

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

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

********经验与建议10：********态度

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

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

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

05

**Mentor方面
**

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

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

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

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

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

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

两者的区别：

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

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

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

两者的表现：

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

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

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

06

**最后
**

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

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

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

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

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

- END -

喜欢的加入我的免费知识星球：觉醒的新世界程序员，随时与我沟通，交流技术与想法。

​

喜欢的也可以关注我的公众号：​无处不在的技术​，与我一起学习成长、共同进步，在技术的道路上越走越远。

---

Original 无处不在 无处不在的技术

---

内容效果不满意？点此反馈