這個深有體會,說來都是淚啊,我想大部分程式設計師一想到的就是重構,個人認為應該從兩個團體去分析看待這個問題

新員工屬於積極又弱勢的群體,剛進公司,往往急於表現自己卻又對業務和工程不熟悉,只能依託專案文件和老員工口頭相授.而文件對於大部分公司是不存在.面對低內聚高耦合的程式碼,,你只能祈求它不出bug,否則能分分鐘讓你心律不齊,開始有了更新簡歷的念頭;這時候可以求助於老員工幫你解決遺留程式碼的bug,因為大部分就是這些人寫出來的程式碼 - -! .這完全取決於老員工的人品和心情.這時候的內心一般是這樣的: 我要重構,我要解耦 → 業務不熟,重構困難 → 艱難重構,bug變多 → 產品,測試抱怨,為什麼bug越改越多,能力受到質疑 → %>_<% 吃力不討好,從重構到放棄.

老員工團體對業務和程式碼已經非常熟悉,有了一定層度上的惰性,主動尋求重構的畢竟不多,對待低內聚高耦合的程式碼已經不會產生排斥感,甚至成為了遺留程式碼的堅定守護者:程式碼long long ago已經是這樣的,我也不知道為什麼,修修補補就好了,反正能執行,幹嘛要重構,到時候出問題誰負責...

對待低內聚高耦合的程式碼,無非兩種:重構或微調.

重構治本,但需要一段時間收斂bug,這就需要專案帶頭人評估工時,權衡利弊,帶起團隊開始重構,並對內對外扛起責任.

微調,如果重構的成本和代價太大,微調也是可以接受的,畢竟產品上線,正常執行優先順序級比較大.至於程式碼不好改什麼的,噁心噁心就習慣了,who care...