北京
入職第一天，我背著滿腦子設計模式、UML圖和Clean Code理論走進辦公室。三天后，我發現自己對著一份五年前的遺留代碼發呆——寫它的人早已離職，而我要在不破壞現有功能的前提下，修復一個邊緣case。
這不是我幻想中的開發工作，但這才是真實的工作。
以下是我用撞墻換來的經驗。如果你剛入職或還在試用期，希望能幫你少踩幾個我踩過的坑。
核心清單：讀懂他人代碼、用論據而非觀點提建議、寫有用的測試、記錄所學、先問再寫、理解業務、快速求助、在會議里發言、記錄工作成果、加入技術社區。聽起來像廢話？但確實沒人提前告訴我。
一、讀懂代碼比寫代碼更重要
我原以為入職后會從零搭建系統，用上六角架構和各種設計模式。現實是：我花了兩周讀一個離職同事寫的函數，試圖理解它為什么那樣實現。
初期很挫敗。后來才意識到，這就是工作的本質。
大部分時間你在修補現有系統：加一個小功能，修一個bug，同時保證不碰壞其他東西。快速閱讀他人代碼的能力，才是新人真正的分水嶺——比你會什么框架、背過什么模式都重要。
實操建議：進新項目后，先花兩三天純閱讀。不動手改。記筆記、手繪流程圖、列出疑問點。開始編碼后，你會感謝這幾天的投入。
二、用論據說話，別只給觀點
我見過巨型遺留系統，單體架構支撐著無數下游團隊。我當時想推動微服務改造、框架升級、全面現代化。
沒人理我。他們是對的。
遷移這類系統動輒數月甚至數年，而業務不能停、客戶還在付費。沒人會為了你的技術理想按下暫停鍵。
后來我懂了：新人提建議能否落地，差距在表達方式。"我們應該升級這個"是觀點；"當前版本有已知安全漏洞，遷移需兩個sprint，不遷將承擔XX風險"才是論據。
實操建議：提技術債務或架構調整前，先算清成本、風險、收益。帶著數字和替代方案去聊，別只帶熱情。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
