入職第一天,我背著滿腦子設計模式、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.