入职第一天，我背着满脑子设计模式、UML图和Clean Code理论走进办公室。三天后，我发现自己对着一份五年前的遗留代码发呆——写它的人早已离职，而我要在不破坏现有功能的前提下，修复一个边缘case。

这不是我幻想中的开发工作，但这才是真实的工作。

打开网易新闻 查看精彩图片

以下是我用撞墙换来的经验。如果你刚入职或还在试用期，希望能帮你少踩几个我踩过的坑。

打开网易新闻 查看精彩图片

核心清单：读懂他人代码、用论据而非观点提建议、写有用的测试、记录所学、先问再写、理解业务、快速求助、在会议里发言、记录工作成果、加入技术社区。听起来像废话？但确实没人提前告诉我。

一、读懂代码比写代码更重要

我原以为入职后会从零搭建系统，用上六角架构和各种设计模式。现实是：我花了两周读一个离职同事写的函数，试图理解它为什么那样实现。

初期很挫败。后来才意识到，这就是工作的本质。

大部分时间你在修补现有系统：加一个小功能，修一个bug，同时保证不碰坏其他东西。快速阅读他人代码的能力，才是新人真正的分水岭——比你会什么框架、背过什么模式都重要。

实操建议：进新项目后，先花两三天纯阅读。不动手改。记笔记、手绘流程图、列出疑问点。开始编码后，你会感谢这几天的投入。

打开网易新闻 查看精彩图片

二、用论据说话，别只给观点

我见过巨型遗留系统，单体架构支撑着无数下游团队。我当时想推动微服务改造、框架升级、全面现代化。

没人理我。他们是对的。

迁移这类系统动辄数月甚至数年，而业务不能停、客户还在付费。没人会为了你的技术理想按下暂停键。

后来我懂了：新人提建议能否落地，差距在表达方式。"我们应该升级这个"是观点；"当前版本有已知安全漏洞，迁移需两个sprint，不迁将承担XX风险"才是论据。

实操建议：提技术债务或架构调整前，先算清成本、风险、收益。带着数字和替代方案去聊，别只带热情。