10年老碼農：如何從該死的爛程式碼中爬出來？

老前輩的警世良言一定要牢記：重構一時爽，頭髮不再長。

還有，工作了10年的碼農，到了新公司，絕不會說這種話。

不過話說回來，能覺得模組程式碼爛，還能擼起袖子去改的程式設計師，真是很難得的一種精神。我身邊 90%都是隻是嘴上說，絕對不動手乾的。下一次下一次下一次，無數的下一次造就了爛程式碼。

到底要不要重構？

很多人口中的重構就是重寫，而不是去改善現有的程式碼。

現在的有些工程師太浮躁, 動不動就要重構, 就跟很多的團隊動不動就要搞一個框架一樣。

說實話，以我個人的經驗來說，絕大多數開發人員到新公司後，都會覺得程式碼很爛，但通常他不瞭解業務邏輯是怎麼變化的，這種程式碼是在什麼情況下寫出來的，有什麼特殊的背景，除了真的是亂搞的，絕大多數的“爛程式碼”一般都是有原因的：業務需求改改改，有多少坑其實很少有人能在極短時間內把所有的坑都找出來。

如果貿然去重構，風險非常大。而且再說難聽點，就算重構完了，也有可能是一堆新的“爛程式碼”替換老的“爛程式碼”。

所以，進了一家新公司，別動不動就重構，先了解專案的業務邏輯。

到底要不要離職？？？

其實在我看來，如果僅僅因為接手程式碼太爛，就選擇離職，那麼你跳槽到下一個公司依然會面對同樣的現狀，因為幾乎每個人，都會覺得自己公司的專案程式碼很爛。

我們先說說造成這種現象的原因是什麼，首先，我們得相信，沒有任何一個人故意把自己的程式碼寫的很爛，每個人都想把自己的程式碼寫的很優雅，擴充套件性很好，但是可能當初水平不夠，在當時看似還不錯的程式碼，日後在別人看來就是所謂的垃圾程式碼。

我們每個人都在進步，別說別人了，你現在看你三個月之前的程式碼，可能你都會覺得寫的很垃圾，如果你沒有這種感覺，只能說你在止步不前。

其次，技術更新換代太快，市場的變化也太快，產品自然也一直在演變，也許在當時看起來還不錯的程式碼，隨著時間的推移，功能的更新，程式碼的堆徹，慢慢就變成後來者眼中的爛程式碼了。

從該死的爛程式碼中爬出來 ！

產品需求與業務流程文件，這些是你先要找到的，你接手的程式碼，必然和某個產品需求相對應，必然實現了某個業務流程，先了解產品需求和業務流程，才能更好的讀程式碼。

瞭解了產品需求和業務流程，最好能體驗一下軟體，從使用者的角度來理解軟體的使用。這個時候你要麼需要生產環境，要麼需要測試環境。哪個環境不重要，重要的是，你需要一個能Run，能體驗的軟體。

負責交接程式碼給你的那位同事，要麼在辦離職，要麼已經介入了其他產品，眼下很可能已無心戀戰，但你心裡要清楚，只有他才能提供程式碼層面的東西，比如類圖、模組劃分說明、資料流圖、時序圖、狀態圖等等。

所以，你需要他整理一些文件和圖表出來。你可以告訴領導你需要上面的東西，讓領導和他溝通，讓他在離開之前準備好這些文件給你，並留一些時間以便你熟悉。

不要被浩渺如煙並且陌生怪誕的程式碼嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。

最後，當你再碰到這種事兒的時候，請記住老前輩的這句警世良言：

那些不能將你擊潰的程式碼，都將成為你成長的墊腳石。

自己是從事了五年的前端工程師，不少人私下問我，2019年前端該怎麼學，方法有沒有？

沒錯，年初我花了一個多月的時間整理出來的學習資料，希望能幫助那些想學習前端，卻又不知道怎麼開始學習的朋友。