不該跑路。有問題的地方，一旦你能解決，就是機會！ 積弊越深，空間越大！
一個類能寫9000行，這說明程式碼的質素很差，進而說明之前的程式設計師甚至架構師的水平很菜。正是你進行重構和提升程式碼及產品質素的好機會。
這樣的程式碼，會伴隨著產生各種各樣的程式問題，從而出現很多產品問題。另外，產品的維護和軟件功能的叠代會變得極其困難。如果你能把這些問題都解決了，實打實地讓軟件質素和產品質素有提升，那麽，個人能力的提升和升職加薪都是水到渠成的事。
到一家公司工作，本質上就是要幫boss解決問題，你能解決的問題越多越復雜，說明你的價值越大，如果讓boss看到了你產生的價值，就會體現到你的收益和職位上。
舉一個我親身經歷的事。
我曾經在一家公司就遇到這種情況，當時那家公司的人力資源VP剛好是前華為同事，他很清楚當時研發團隊的水平糊軟件產品質素，我入職的時候，他就有意識的跟我講：現在的公司和華為在研發能力和人員水平上肯定是有很大差距，以後能看到各種各樣的問題一定是很正常的，但不要遇到問題就抱怨，這些正是能提升能發揮價值的地方。從我後來的經歷來看，深以為然。
那家公司的程式碼能差到什麽程度？一個檔上萬行，一個函數幾千行，函數中有大量的連續上百行沒有空行的程式碼，static變量到處飛，很多的類名、函數名甚至變量名牛頭不對馬嘴，功能實作錯位，到處是越界隱患，例外處理幾乎沒怎麽考慮，沒有偵錯日誌，大量的重復程式碼和廢氣程式碼。真是毫不誇張的說。
當時第一眼看到這份程式碼的時候，我想死的心都有。難怪產品經常出問題，一出問題又很難定位，人員也流失嚴重，疊加新功能周期很長，舊產品維護投入的人力很大，沒人願意加入那個團隊。
但，正是這一個團隊和業務，我把它帶起來了，後來我的影響力也在整個研發事業部中建立了起來。
我采取了一系列舉措：
1）先把現狀和產生這麽多產品問題的原因，跟boss講清楚，得有理有據；
2）如果由我來改進這一攤子事，要大刀闊斧地做哪些變更，需要多少人，需要多少時間，跟boss講清楚。包括架構重構、制定程式碼規範、明確要整改到什麽程度、制定整改計劃、分模組進行程式碼整改、借助哪些工具（程式碼靜態檢查、記憶體檢測工具等）、團隊成員能力怎麽提升、怎麽檢視程式碼、怎麽驗證、怎麽保障產品質素、怎麽在這個過程中形成好的氛圍提升團隊戰鬥力，等等。
3）給出階段性效果，比如程式碼質素的改善、產品質素的提升等。讓boss能即時了解情況，才會放心大膽地放手放權給你幹。
這裏面如果展開講可以講幾天。大家如果感興趣，後續再補充。
關於這方面程式碼質素的提升，有幾本書可以參看一下：【重構-改變既有程式碼的架構】、【程式碼整潔之道】、【聊聊「架構」】、【設計模式之禪】。
【* 如果有所幫助，不妨點贊、收藏、加關註。IT技術管理、個人進階，分享不一樣的見解。*】
