1樓：
劃分成模組，混成一團就劃分乙個大模組，只對公共介面寫好文件，這樣即使裡面一坨屎，也沒用辦法修改，但是還可以繼續用，修改就新建乙個模組實現新的功能。這樣就把那坨屎個從今後的開發中隔離了出去
2樓：鄒科
除非能承受大動干戈的代價， 否則還是先治標，後治本。 治標可以解決具體問題，其次可為治本打好基礎和積累經驗。 就如乙個社會事件出現時，我們首先是解決具體事件，之後要從問題要反思，改變相關制度，然後大家遵守之，這是乙個長期的過程。
3樓：色色魚
拿這員工的錢，操著老闆都不操的命，從工作角度，盡量折中權衡，從提公升個人角度，可以私下試試改造，按題主的描述，這基本是病入膏肓的產品了，老闆估計在跟甲方談新一套產品了。。。。。
4樓：旺旺
這就是所謂的「技術債務」。
就跟公司債務不能全靠會計解決一樣，程式設計師能發揮的作用有限。
當然，作為乙個程式設計師，職業道德裡確實應該包含《Clean Code》裡說的"童子軍規則"：以當童子軍為榮，以有女朋友為恥！（錯了，錯了，不是這個，是當你離開乙個地方的時候，要讓它比你來的時候更整潔乾淨。
）不要重構！不要重構！不要重構！（三體人從半人馬座發來遙遠的問候～～）
5樓：
從技術上講，逐個重構業務是風險最低最可行的，但是代價就是「新壺裝舊酒」，最終只是在向正確的方向上做了些微調，而付出的成本卻是最高的，週期也是最長的。
鑑於一般專案發展到這種狀態基本上已經沒有可能推倒重來了，所以最可行的方法還是發揮愚公移山的精神，一點點的重構吧。反之，如果條件允許，推倒重來是最高效最高回報的方式。風險與收益成正比。
關於重構的實施和團隊分工，應該是老團隊支援業務需求，組織更高水平的新團隊完成重構，這樣才最穩妥。都知道一旦重構完成了老系統就作廢了、老團隊就沒有價值了，所以一旦進入重構環節都會去爭搶好位置。這是最考驗團隊管理能力的時刻，既要對新團隊充分授權和支援，還要給老團隊的核心成員合適的激勵以安撫人心，確保新老知識體系接續順暢。
但是，如果公司管理層不正視這些問題，必然沒有人會去做重構的事，只能湊活著吧。
6樓：小蝶驚鴻
像這種系統，我們TFS上面一大堆（十來個吧？！反正絕對超過十個）大部分都是純手寫的哦（當然不是我寫的，我是專門來擦屁股和優化的）。
隨隨便便開乙個aspx都千把行JS，隨隨便便開個js檔案都3K+行JS，隨隨便便開個.cs檔案都幾千行，隨隨便便展開個方法都幾百行，你跟我說推了重寫~~？！
別想了，就這套破玩意也是百多號人用了幾年才寫出來的，現在每天還在遷入大量的Code呢。
實在忍不了，大不了直接走人，沒什麼大不了的事情~~
程式設計師如何挽救乙個失敗的專案？
倉木 難道只有我乙個人認為這不是技術問題嗎？問題根源不在技術上，為什麼要用從技術上去解決問題？首先 當前專案的運營收益什麼情況？其次 老闆願意投入多少費用進行現系統的公升級重構，投入的費用和公升級重構後需要達成的目標？最後 那些只認識0和1的攻城獅，程式猿可以上了。我認為解決問題的前提是你有什麼資源...
Java程式設計師 面試如何介紹專案經驗？
1.當面試官讓你簡單說說或介紹你的專案的時候。只要面試官有提到 簡單 這兩個字，你只需要簡單說下專案的業務背景 用到的技術棧，你負責的內容。至於你具體的工作內容和專案技術難點不用說。面試官感興趣了自然會問。2.當面試官讓你說說對這個專案的了解或熟悉程度。這個代表著面試官讓你自由發揮，你就得從業務背景...
如何面試程式設計師？
hsmcomputer 1 看簡歷，考核專案經驗，有經驗的面試官，會看出簡歷上的專案是編造的還是真實的專案。2 讓說最近乙個專案裡用到的技術，考核技術在專案裡的用法。3 看標準，初級的話看基本用法，就增刪改查，高階的外帶調優，架構師看分布式元件和設計思路。4 技術過關了，看團隊協作等軟實力。大多數程...