事情是這樣的，前幾天在朋友圈，我看到一朋友發表了一條說說：“入職新公司，從重構代碼到放棄”，我就問他怎麼了？他說，剛進一家新公司，接手代碼太爛，領導讓我先熟悉業務邏輯，然後去修復之前項目中遺留的bug，實在不行就重構。
關鍵是，離職的那位仁兄走之前，還跟我在QQ上說，老哥辛苦了，我寫的很亂真不好意思，但我是故意的。
這幾天，我都在想，要不要離職？
———
聽完你的遭遇，我想先說一句，離職那位仁兄太狠了！！！
其次，我相信，這個問題很多人都遇到過。
每個新人去一家新公司都會覺得公司代碼很爛，可能是因為他沒被產品虐過。
其實，這種新員工很不錯了，一看就是真萌新，重構這種事，老闆看不到 KPI，出了事還得自己兜底，還會得罪人，費力不討好，何必呢！
老前輩的警世良言一定要牢記：重構一時爽，頭髮不再長。
還有，工作了10年的碼農，到了新公司，絕不會說這種話。
不過話說回來，能覺得模塊代碼爛，還能擼起袖子去改的程序員，真是很難得的一種精神。我身邊 90%都是隻是嘴上說，絕對不動手乾的。下一次下一次下一次，無數的下一次造就了爛代碼。
「 要不要重構 」
很多人口中的重構就是重寫，而不是去改善現有的代碼。
現在的有些工程師太浮躁, 動不動就要重構, 就跟很多的團隊動不動就要搞一個框架一樣。
說實話，以我個人的經驗來說，絕大多數開發人員到新公司後，都會覺得代碼很爛，但通常他不瞭解業務邏輯是怎麼變化的，這種代碼是在什麼情況下寫出來的，有什麼特殊的背景（除了真的是亂搞的，絕大多數的“爛代碼”一般都是有原因的：業務需求改改改，這個需求明天就要上線等等等等），有多少坑（很少有人能在極短時間內把所有的坑都找出來）。
如果貿然去重構，風險非常大。而且再說難聽點，就算重構完了，也有可能是一堆新的“爛代碼”替換老的“爛代碼”。
所以，進了一家新公司，別動不動就重構，先了解項目的業務邏輯。
「 要不要離職 」
其實在我看來，如果僅僅因為接手代碼太爛，就選擇離職，那麼你跳槽到下一個公司依然會面對同樣的現狀，因為幾乎每個人，都會覺得自己公司的項目代碼很爛。
我們先說說造成這種現象的原因是什麼，首先，我們得相信，沒有任何一個人故意把自己的代碼寫的很爛，每個人都想把自己的代碼寫的很優雅，擴展性很好，但是可能當初水平不夠，在當時看似還不錯的代碼，日後在別人看來就是所謂的垃圾代碼。
我們每個人都在進步，別說別人了，你現在看你三個月之前的代碼，可能你都會覺得寫的很垃圾，如果你沒有這種感覺，只能說你在止步不前。
其次，技術更新換代太快，市場的變化也太快，產品自然也一直在演變，也許在當時看起來還不錯的代碼，隨著時間的推移，功能的更新，代碼的堆徹，慢慢就變成後來者眼中的爛代碼了。
「 如何從爛代碼中爬出來 」
假如你真的要接手別人的代碼，怎樣才能不被玩兒死呢？
雖然你可能會說，聽了很多道理，依然交接不好代碼，可作為經常被別人的代碼玩得欲仙欲死的老司機，我有些話如鯁在喉，不吐不快。
當你被要求接管要離職的程序員的代碼時，如果能注意以下幾點，就有可能活著從他的代碼裡爬出來。
1. 產品需求與業務流程文檔
產品需求與業務流程文檔，這些是你先要找到的，你接手的代碼，必然和某個產品需求相對應，必然實現了某個業務流程，先了解產品需求和業務流程，才能更好的讀代碼。
假如你的團隊就是沒文檔，Ok，也可以要求離職或轉移戰線的這位程序員把需求描述出來，把業務流程畫出來。
2. 測試環境
瞭解了產品需求和業務流程，最好能體驗一下軟件，從用戶的角度來理解軟件的使用。這個時候你要麼需要生產環境，要麼需要測試環境。哪個環境不重要，重要的是，你需要一個能Run，能體驗的軟件。
3. 業務流程在代碼層面的體現
負責交接代碼給你的那位同事，要麼在辦離職，要麼已經介入了其他產品，眼下很可能已無心戀戰，但你心裡要清楚，只有他才能提供代碼層面的東西，比如類圖、模塊劃分說明、數據流圖、時序圖、狀態圖等等。
所以，你需要他整理一些文檔和圖表出來。你可以告訴領導你需要上面的東西，讓領導和他溝通，讓他在離開之前準備好這些文檔給你，並留一些時間以便你熟悉。
4. 讀代碼，不死不休
有了產品需求，有了業務流程，有了代碼設計相關的文檔和圖表，接下來你就該死磕代碼了：
while（不懂）{ 讀}5. 開發環境與調試
有的產品需要比較複雜的開發環境配置，一定要提前做好，讓即將離開的同事輔導你搭建好開發環境，這樣你就可以利用“調試”這個強大的武器來快速理解代碼了。
調試是接手別人代碼時的利器，如果你看不明白一個業務在代碼層面是怎麼體現的，也看不懂代碼之間的調用關係，那最好的辦法就是調試。從一個業務的起點所對應的代碼開始調試，一步一步跟進去，就能快速理清函數調用鏈。
6. 樹立可實現可衡量的目標
程序員的工作交接，尤其是代碼交接，怎樣才算順利完成呢？
這簡直就是一個謎！
沒人說得清楚。
所以，你最好給自己梳理一些可衡量的、可實現的目標。比如讀懂A、B、C三個業務流程……
最好，找一個Bug或者一個新增的功能，帶著目的去讀代碼、修改代碼，有目的，有目標，有時間盒，就容易投入，容易讀進去，容易掌握與Bug或新增功能相關的代碼的邏輯與流程。
7. 輸出、分享與重構
你在讀代碼時，如果能撇開給你交接工作的程序員提供的文檔，按自己的理解，自己繪製類圖、數據流圖、時序圖、關鍵業務流程對應的函數調用關係鏈等，就能更快的掌握別人的代碼。
如果你還能將你理解到的東西，講給其他人聽，並且講明白，那Ok，你真的理解了別人交接給你的代碼。
再進一步，如果你在理解現有代碼的基礎上，可以識別出哪些部分實現得邏輯不清晰或有待改善，然後可以結合業務與自己的理解將其重構，那就真的是完全接手了別人的代碼，別人的代碼與你的代碼就沒有差別了，它們終將成為你的代碼。
「 最重要的事兒 」
如果你總是看見代碼多就發愁，看見代碼髒亂差就詛咒埋怨，看見代碼邏輯複雜就頭疼，搞不清調用關係就放棄，那你可能永遠也變不成代碼的主人，只能一次又一次被代碼蹂躪。
所以，其實交接代碼最重要的事兒，就是：
不要被浩渺如煙並且陌生怪誕的代碼嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。
最後，當你再碰到這種事兒的時候，請記住老前輩的這句警世良言：
那些不能將你擊潰的代碼，都將成為你成長的墊腳石。
十五年編程經驗，整理了一批2019年最新WEB前端教學視頻，幫助所有想要學好前端的同學，不論是學習規劃、學習路線、學習資料、問題解答。只要關注我的頭條號，私信我【前端】兩個字，就可以解決所有學習問題了。閱讀更多 前端技術教學分享 的文章
