开发新人入职首周避坑指南：环境搭建、需求评审与Git协作

入职第一天，我抱着“好好干、多学习”的心态走进工位，结果第一个星期就把自己干懵了。开发环境装到怀疑人生、需求评审会上一句话没听懂却疯狂点头、一把 git merge 差点把同事的代码全冲掉、写了两天的接口被一句话打回重做。这篇文章是我开发首周的真实踩坑记录，主要面向刚入职场的开发新人，也适合带新人的老手看看你的新同事到底是怎么“挂”的。如果你正在准备实习或刚接手第一份开发工作，这篇文章能帮你少走很多弯路。

说实话，我在入职前觉得自己准备得还行，大学里写过项目、刷过题、毕业设计也拿了不错的成绩，至少“写代码”这件事不算陌生。可真到了公司，我才发现学校里那套和公司里这套完全是两回事，差的不是编程语言熟练度，而是从“会写代码”到“在团队里交付代码”之间的一整条鸿沟。第一周我踩的每一个坑，单独拎出来都不算大，但它们连在一起，就成了一个新人最真实也最狼狈的首周记录。本文记录的是上半部分，从环境搭建到第一次代码提交，我尽量把当时的心理活动、错误操作和后续补救方法都写清楚。

1. 入职第一天：环境搭建就是一道下马威

1.1 开发环境不是“装完就行”这么简单

第一天上午，leader 丢给我一台配好的电脑，说了一句“你先搭环境，看下项目文档，下午我找你聊”。当时我还觉得挺轻松的，装个环境而已，能有多难？结果这一搭就是整整一天半。

我犯的第一个错误是把“搭环境”理解为“装软件”。实际上，公司项目环境的搭建通常包含几个完全不同的层面：

• 基础运行时：JDK、Node、Python、Go 这类语言环境，版本要求极其严格
• 包管理与镜像源：npm、Maven、pip 需要配置公司内部镜像源，否则依赖根本拉不下来
• 数据库与中间件：MySQL、Redis、MQ 等，本机版本要和开发环境对齐
• 项目配置：配置文件里的各种地址、密钥、端口号，需要找对地方改
• 内部工具链：公司的代码规范插件、提交检查钩子、内部的研发平台账号权限

我一开始就闷头装了个最新版 JDK，结果项目要求的是 Java 8，用 Maven 一编译就开始报错。最难受的是，我并不知道是 JDK 版本的问题，还以为是代码的问题，浪费时间在那看代码逻辑。后来才明白，公司项目不说“最新”，只认“稳定”，所有版本号在文档里写着 8、11、17，你就老老实实装对应版本，别自作聪明。

注意：如果你入职第一天发现文档里的版本号和你本机的不一致，优先按文档来，千万别用“新版总比旧版好”的思路。开发环境追求的是和团队一致，不是追求新。

1.2 环境变量、镜像源和私有仓库才是真正的拦路虎

如果说装 JDK 还算顺利，那后面的事情就完全失控了。npm install 装到一半报错、Maven 依赖下载超时、Git 拉私有仓库时提示权限不对，每一样都是我在学校没遇到过的。

先说镜像源。学校项目里用默认源，虽然有时候慢一点，但基本能装。公司项目不同，依赖数量和体积巨大，如果走默认源基本是等死。而且很多公司内部发布的 SDK 和公共组件，只存在于内部私有仓库里，外部源里根本没有。你得找到公司内部搭建的 npm registry、Maven repository 地址，配置到全局或者项目的 .npmrc、settings.xml 里。

我举个例子，Maven 的 settings.xml 如果不配置公司私服地址，你在拉某个内部依赖时会看到 Could not find artifact xxx 这样的提示。当时我盯着报错看了半小时，完全没意识到要去找私服地址，后来问了旁边的同事，才知道这个项目有好几个内部依赖必须走私服。

环境变量也是个坑。Windows 上多个 JDK 版本并存时，JAVA_HOME 指向谁、PATH 里的顺序是啥，都会影响实际生效的版本。有人装完 JDK 8 发现 java -version 还是老的版本，大概率是环境变量没生效或顺序不对。建议用终端专门执行 echo $JAVA_HOME 或者 java -version 来验证到底用的哪个版本，别凭感觉。

第一天我就在这种“反复依赖失败 -> 查资料 -> 试错”的循环里度过。到了下午，leader 找我聊需求，我表面上在听，脑子里全是“mysql 连不上怎么办”。现在回头看，环境搭建这种事，第一步最有效的做法不是闷头硬啃，而是：先问同事要一份完整的环境搭建文档，或者让同事直接给你看一下他的配置，照着一步步来。

1.3 新人装环境的核心建议：时间盒与技术债

环境搭建确实会消耗大量时间，但我觉得新人最该懂得的一个词是“时间盒”。你给自己设定一个时间上限，比如“一个小时内如果还没搞定，必须找人求助”，而不是坐那里从早干到晚。环境问题看起来是技术问题，其实是信息问题——你缺的不是能力，而是公司内部的“上下文”。

我在第一周的一个深刻体会是：环境搭建中遇到的问题，90% 以上都是“你知道这里有个配置文件就能解决”的问题，而不是需要深入源码分析的问题。但问题是，刚入职的你真的不知道那些配置文件在哪里。所以，最直接的策略是：

• 先找文档，看有没有现成的环境搭建步骤
• 再找同事，问对方能不能发一份自己的配置参考
• 最后才自己试错，并且严格控制试错时间

这个顺序搞反了，就会像我一样，第一天全耗在环境上，结果工作一项没推进，晚上还焦虑得睡不着。

2. 需求评审：你没听懂，但你不敢说

2.1 需求评审会上最容易踩的坑

入职第三天，我参加了人生第一次正式的需求评审会。产品经理放了十几页原型图，开始讲各种业务场景、异常分支、交互细节。我坐在那里，耳朵里全是不熟悉的业务名词，什么“SKU”“SPU”“渠道”“活动因子”，每个字我都认识，连在一起就不知道在说什么。

但我当时没有提问，而是选择了沉默。原因很复杂：一是怕暴露自己什么都不懂，二是觉得“大家好像都听懂了，我要是问出来会不会显得很蠢”，三是想着“听完之后可以自己看文档补课”。

结果需求评审一结束，leader 让我评估工时，我只能支支吾吾地说“大概两天”。其实我连要做什么都捋不清，那个“两天”完全是我瞎蒙的。后来的事情印证了这一点，我花了两天时间做完的功能，在 code review 时直接被打回：没有考虑业务上非常重要的边界情况。

现在总结一下，需求评审会上新人最容易踩的坑大概有这么几个：

• 当场不提问，回去才发现一堆问题，又不好意思再问
• 把“听懂了大概方向”误解为“理解了全部细节”
• 不敢确认验收标准，导致做完的东西不符合预期
• 忽略非功能需求，比如权限、日志、性能、异常处理

2.2 用什么方式提问才不显得“蠢”

我后来发现，“在评审会上提问”是新人最容易犯怵的事情，但实际问题不在于“要不要提问”，而在于“怎么提问”。如果觉得一个问题太基础，可以用这样的句式：

• “这块我以前没接触过，能不能帮我确认一下……”
• “我想确认下我对这个需求的理解，它的核心目标是不是……”
• “如果出现 XX 这种情况，我们期望的系统行为是？”

这种问法比直接说“我不懂”要好得多，至少让别人觉得你是在确认边界，而不是脑袋空空。而且事实上，很多你认为“只有自己不懂”的东西，其他人也未必真的懂。需求评审会上那些沉默的老同事，可能也在心里犯嘀咕，只是他们经验丰富懂装懂罢了。

2.3 动手前必须确认的三件事

第三周我学到的经验是，接到任何需求后，动手写代码之前至少要确认三件事：

1. 需求背景：为什么要做这个功能？解决谁的什么问题？没有这个背景知识，你连代码里的很多“奇怪”逻辑都会看不懂。
2. 验收条件：什么样的输出才算做完？不要自己发明一套“我觉得这样就行”的标准。
3. 涉及范围：这个功能要改动哪些模块？会不会影响已有的接口或页面？

我建议新人接到任务后，先用自己的话把需求复述一遍，发给产品或直属 leader 确认，得到回复后再动手。这一步看起来麻烦，但实际能避免大量返工。我在第二周就用了这种方法，需求理解准确率明显上升，虽然看起来“多花”了一点沟通时间，但总比做错了重做要省太多时间。

3. Git 协作：第一周最容易翻车的地方

3.1 分支与提交规范：别让你的 commit 变成事故现场

我在学校做课程设计的时候，Git 的基本用法就是 commit、push，项目的分支也就一个 main。到了公司才发现，开发流程里的分支管理、提交规范、代码审查机制完全是一个新的世界。

我头一次提交代码就把事搞砸了：我直接在 dev 分支上改代码，commit message 写的是“fix bug”，然后 git push 就想提测。结果被同事拦住，说让我先看看团队的分支模型。看了文档我才知道，项目用的是 Git Flow 风格的分支策略，dev 分支基本是全组共享的，新人改代码要先从最新的 dev 拉出个人分支，在个人分支上开发，最后再通过合并请求合回去。

还有 commit message。我以前觉得“写什么都行，反正代码能跑就行”。但团队要求的是 feat:、fix:、refactor:、docs: 这样的约定式提交格式，而且 message 里要简洁清楚描述变更内容。刚开始我很不适应，觉得这是形式主义。后来看别人 review 代码时，真的是靠 commit message 来快速了解改动意图的，我才意识到规范的价值。

3.2 merge 冲突：处理不当就全没了

如果说分支规范还只是流程问题，那 merge 冲突就真的是技术问题了。第五天，我的个人分支和 dev 分支产生了冲突。当时我用 IDE 的冲突解决工具，看到一堆 “ours” 和 “theirs” 的选项，凭借直觉选了一通，然后点了“Accept All”，结果就是把同事的最新代码全覆盖成了我本地旧版本，还自信地提交了 merge。

消息传出来还是很快的，没多久就有人发现 dev 分支上的一个模块代码被回退了。最后是 leader 带着大家一起 git revert，又把丢掉的那些提交找回来，折腾了好几个人、两个多小时才恢复。当时我真的非常尴尬。

从那以后，我给自己定了一个铁律：合并代码时，必须逐块检查冲突，任何拿不准的冲突都先停下来。千万不要直接把某个版本的代码全部覆盖，因为那些冲突区域里可能带着同事很重要的逻辑。最靠谱的做法是，逐个冲突点看代码上下文，弄明白双方各自在做什么，再决定保留哪边、怎么融合。如果遇到实在看不懂的，就找人一起看，别自己硬选。

3.3 自己拉分支、频繁提交、及时同步

经历了那次事故，我整理出了对新人最友好的 Git 协作“保命”方案：

• 自己开发一定要拉个人分支，不要在公共分支上直接改
• 开发过程中频繁提交，commit message 写得清晰些，一个功能点一次提交
• 每次开始干活前，先同步最新 dev，减少最终的冲突范围
• 代码合并前，自己先在本地解决冲突，别直接推到远端

你会发现，这些习惯在团队里不是“加分项”，是“基本要求”。如果这些做不到，代码根本走不到 review 那一步，在合入前就会被人拦下来。

4. 代码规范与团队协作：不是“能跑就行”

4.1 代码风格问题：ESLint / Prettier / 格式化插件要装齐

第一周我最深的“文化冲击”，是团队对代码风格的要求。我之前写代码的风格是“能跑就行”，缩进有时候两个空格有时候四个空格，字符串单引号双引号看心情。到了公司，提交代码前要先通过 lint 检查，各种空格、引号、换行的问题都会直接让 CI 失败。

我一开始很不耐烦，觉得这些都很琐碎。直到 reviewer 在我的代码上留了一堆关于“命名不规范”“函数太长”“重复代码”的评论时，我才意识到代码风格不是个人审美，而是团队协作的基础设施。大家的代码风格统一了，diff 看起来才清晰，review 效率才高，维护起来才不痛苦。

我入职后最初几天，就把团队用的 ESLint 规则、Prettier 配置、EditorConfig 全装齐了。IDE 里配置“保存时自动格式化”，写代码的时候顺手处理掉格式问题，不要攒到最后。另外，团队如果要求某些命名风格，比如变量用小驼峰、组件用大驼峰、常量用全大写，都要严格遵守。这些不是给你找麻烦，是为了让整个项目的可读性保持一致。

4.2 求助的艺术：把问题问得“值钱”

第一个星期，我还遇到了一个普遍矛盾：遇到问题不知道该不该问同事，问了又怕显得自己能力不行。我的做法是先自己憋，憋到实在不行了才开口，结果问的时候心情已经很焦虑，表达也混乱，问完之后对方也没完全理解我在问什么。

后来一个 nice 的同事给我讲了一个方法，非常管用，我到现在还在用。他说：“问问题之前，先把你做过的尝试列出来，把你怀疑的原因写出来，再把你希望对方帮你解答的问题说出来。你不是来让对方帮你写代码的，你是来获取信息的。”也就是说，提问本身也应该是“专业”的。

我建议新人准备一个“问题记录”的文档，每次遇到问题先自己排查、记录排查过程，确认自己解决不了后再求助。问的时候，可以这样说：“我遇到了 XXX 问题，我搜了文档、试了 A 和 B 两种方案，都失败了，相关报错是 XXX，你能帮我看看是不是和 C 有关系吗？”这种问法，对方一听就知道你是有备而来，也更愿意帮你，因为他只需要帮你补充最后一公里的信息，而不是从头带你。

注意：千万不要把同事当成“百度”，遇到任何问题都先问一遍。最多的问题是，你想都不想就开口，或者你问完之后，并没有把答案记录下来，后边又遇到同样的问题又来问第二遍。问过的问题要记下来，这是对同事时间的尊重，也是对自己成长负责。

4.3 code review：第一次被人批，心态别崩

第五天下午，我的第一个功能写完，提交了 review。随后我收到了十几条评论，从“命名不合理”到“这里有一个潜在的空指针问题”，从“函数拆得太碎”到“没有考虑并发场景”。说实话，当时我心情挺低落的，甚至有一点抵触：“我明明都实现了，为什么还这么多问题？”

但冷静下来之后，我发现那些意见绝大多数都是合理的，尤其是那个空指针问题，如果在生产环境触发，后果真的严重。我想说的是，code review 本质上是团队在帮你守住质量底线，不是针对你个人。新人一定要把“别人指出问题”和“别人否定你”这两件事区分开来。受到 review 意见后，尽量“对事不对人”，逐条确认、逐条修改，不确定的可以回复评论继续讨论。

说实话，我的代码质量真正开始提升，就是从认真对待 code review 开始的。第一周十几条评论，第二周就变成几条了。新人的成长速度，很多时候看的是你如何吸收这些反馈。

5. 常见问题与排查技巧实录

5.1 首周高频问题速查表

第一周我经历的大大小小问题里，有很多问题其实是“周期性出现”的。我做了个整理，方便新人在遇到同类情况时快速定位：

5.2 排查问题的通用方法论

很多新人排查问题的方法，本质上是靠“猜”，猜不出来就干瞪眼。我首周吃过很多亏之后，总结出一个简单的排查流程：

1. 复现问题：能不能稳定复现？什么时候必现、什么时候偶发？
2. 看报错信息：找到关键堆栈或关键错误码，不要一开始就被一大段日志吓到，关键信息通常只有几行
3. 查项目文档/搜索：报错信息去掉本机路径后直接搜，大概率能找到同类问题
4. 二分定位：注释一半代码、关掉一半配置，看问题是否消失，快速缩小范围
5. 问同事：带着前面几步的结果去请教

拿依赖报错来举例，第一次看到 npm ERR! code ECONNREFUSED 的时候，我根本不知道是网络问题还是仓库配置问题。后来按这个流程走了一遍，先去搜报错，发现多半是 registry 配置或代理问题，再用 npm config get registry 查看当前源，一下就定位了。

5.3 新人必须养成的三个工作习惯

首周密集的踩坑让我意识到：问题的根源往往不是技术难度，而是工作习惯。有几个习惯我想特别推荐给新人：

第一，记录文档。每天记录自己做了什么、遇到什么问题、怎么解决的。这个文档既是你的成长记录，也是你以后写总结、述职的素材。我后来发现，很多问题过一段时间就会再遇到，有记录能省大量重复排查时间。

第二，及时同步。哪怕你什么进展都没有，也要在站会上如实说“今天还在解决某个问题，卡在哪个点上，计划什么时候搞定”。千万不要因为不好意思，就隐瞒你的“停滞状态”，团队不会因为你慢而怪你，怕的是你卡住了还不说，等到交付日才暴露。

第三，定期复盘。每周五下午花半小时，翻一遍这一周的经历，问自己三个问题：这周做的最有成就感的事是什么？最大的挫败是什么？如果再来一次，我会怎么做？我在入职首周复盘的时候就写下了关于“提问太晚”和“不确认需求”这两条，后面几周刻意改进，效果非常明显。

结尾：首周虽然狼狈，但这些坑价值很大

现在回过头去看入职第一周，我犯过的错确实不少：环境搭建浪费太多时间、需求评审会上沉默装懂、git merge 直接搞坏公共分支、代码 review 被批得怀疑人生。但换个角度想，这些坑早踩晚踩，都是新人成长路上的标配。早踩的好处是，你会在还没承担太重责任的时候就把这些挫折经历一遍，之后真正负责重要需求时，反而会变得谨慎而可靠。

如果你也是刚入行的开发新人，我最大的建议就是：把“不会”说出口，把“不懂”问出来，把“做错了”承接下来，把这些都当作正常的学习成本。职场新人最怕的从来不是犯错，而是犯完之后没有任何成长。首周的经历虽然狼狈，但它给我补上了学校里教不了的那一课——真实世界的软件开发，从来不是一个代码能力的考试，而是一场关于工作习惯、沟通协作和心态的马拉松。

这一篇记录的主要是前五天的经历，从环境搭建到首次代码提交。下一篇我会接着写第二周真正开始迭代需求时的踩坑记录，包括业务理解偏差、单元测试被忽略、联调接口时“我以为你改了但你其实没改”的那些崩溃瞬间，到时候再和大家细聊。