同事離職，我接盤了個垃圾項目，該如何是好？

01-14

我在一家小公司工作，大概就是個醫院的體檢登記項目，代碼凌亂不堪隨處複製粘貼Sql，最悲劇的是項目還是基於.net 1.1/VS2003的。上一個同事接盤的時候，客戶提出了需求，要在體檢表裡增加兩個欄位，但這個同事拖了幾個月之後完全沒搞過，辭職了，然後找我來接盤了，我好像是第4個還是第5個接盤的。
我當時是極力要求把這個項目推到重來，升級到.Net 3.5或者4(當然領導不懂這些)，讓我來重新開發一次，但領導死活不同意，主要是兩點理由，第一點是這個系統各家醫院在用，萬一升級出了什麼差錯導致系統不能使用，這個責任沒人能擔當得起。另外一點政策在變，下一年醫院可能要統一用省的系統，可能不能再用我們的系統，我們現在是能熬一年就熬過一年。
就這樣，我就硬著頭皮在電腦上裝個VS2003，在系統里加了兩個欄位和修改相關功能。但最近發現需求又來了，是一個「黑名單」的功能，而這個功能，早在甩盤給我的那個人，的再往上一個接盤的人那個年代，客戶就已經提出了，結果拖了幾代人都還沒有搞過。

面對這樣重要而又爛，而又不能升級、而又時不時修改需求的項目，大家覺得應該如何處理？

在評論中，看銜木和Yanlin的問題，決定寫一下「打log的心得」，鏈接就看https://zhuanlan.zhihu.com/p/24785018

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

贊數超過輪子哥 @vczh ，真是不勝惶恐。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

我分享一下我的經驗吧。

幾年前，從事LTE 4G核心網的開發，手上的代碼是2G時代的代碼。自己是項目經理，手下六個人，兩個畢業一年，四個應屆生，代碼量是40W行C++。這40W+行代碼，有部分能用，有部分不能用，還有新的需求加上去，一年內左右要差不多能夠商用。經過10個月時間，我們七個人滿足了新需求，加了幾個功能，代碼也削減到30W行。

我面臨的問題，舊代碼太多，年代可以追溯到90年年代。風格比較亂，可以看出有多少人寫過，加功能也很難，而下面都是經驗很淺，甚至沒有經驗的員工，不光要加新功能，還得重構，還得培訓他們，還得審核他們的代碼質量。唯一比較欣慰的就是有一個比較舊的自動化測試框架。

當時我的做法是這樣：

1. 第一步，打log。讓應屆生給代碼打log，寫完之後，提交到crucible上進行review。從這上面給他們改進建議，讓他們熟悉打log的規範，怎麼打出有意義的log。這作為第一步的好處是，它不會改變代碼邏輯，也不會影響代碼，可以放心交給應屆生來做，也可以讓他們知道這些功能大概是什麼。

2. 第二步，拆函數。把一些大函數拆成小函數。讓他們在管的模塊方面，把那些大的函數拆成小函數。每次提交前都要review，並把自動化測試的結果貼上去。在這上面，教他們一個函數只做一件事情的準則。而且由於之前已經打log了，所以他們也很容易定位問題。在熟悉log的基本上，可以讓他們學會用gdb調試

3.第三步，清除和系統API功能相關的代碼。由於第二步完成時，他們負責的模塊一般只有小函數了，而且他們對流程也懂了，這時候讓他們學一些系統API，平時在代碼review時根據代碼邏輯給出建議，讓他們看一下哪些系統API。這樣他們就知道怎麼改了，也嘗到使用系統API的甜頭，就會主動去學系統API。

4.第四步，清除和系統通用工具相關的代碼。在第三步完成之後，他們負責的模塊已經比較好了，但代碼量有時候還是比較多，而這時，他們大概已經比較清楚自己模塊的功能。這時候就要開始進行會議討論和分享。由於代碼比較舊，有些功能現在可以通過一些系統工具實現了。就和他們提一下，讓他們直接調用工具。基本上，這一步對代碼削減就非常大了。

5.第五步，畫圖。在第四步時，已經讓他們開始接觸UML。到第五步，就讓他們把自己模塊的流程用UML畫出來，然後評審，看哪些類是不合理。基本上在這一步，就能夠發現很多沒用代碼，然後就整改。

1~5這幾步，review和自動化測試都要抓緊。特別review，要重視編程技巧和知識面的提示

說句不好聽的：在保證關鍵系統在線率以及效費比上，其實你們領導是對的。

而且，看開一點啦。其實 .Net 1.x 已經很好了，至少能找到的文檔很充足。要是遇到一些不但舊，而且還冷門的才真是哭死呢。

商業應用方面，題主同學你看過 Foxpro 2.6 嗎？哥兩個月前還在幫客戶看。Progress OpenEdge 10 資料庫？現在還在看。

跟政府沾邊的都比較守舊，這點美國也一樣。

我親身看到過的：美軍用的先進中程彈，AMRAAM，至少在C7版本還是有用Pascal寫的指導令。NASA還有很多東西在用 FORTRAN，我有個在JPL工作的同學，現在每天在「非死不可」上吐槽最多的，除了「橙面魔」（川總）之外，就是FORTRAN，然後猛贊Python。問題是：地面上的數據處理可以改用 Python，已經在衛星上、飛出了半個太陽系的東西怎麼辦？

所以啦... 知足常樂

程序員的能力有兩個方面，一是專業技能，一是行業知識。

代碼寫得好，跑得快，這是專業技能；寫出來的代碼要解決什麼問題，如何解決，則是行業知識。就好像銷售一樣，如何溝通，把握客戶心理，是專業技能；了解所賣產品，賣車的懂車，賣電腦的懂電腦，這是他們的行業知識。要想業績好，二者缺一不可。

但作為程序員，往往關注前者，輕視後者。

專業技能帶來機會和抗風險能力，可以選擇公司，適應環境，不會因為某個行業的沒落而陷於困境；而行業知識是門檻和護城河，可以幫你在競爭中保有優勢。做互聯網的，要懂人心；做企業的，要懂業務邏輯；做電信的，要懂telco；做ERP的，要知道進銷存...

為什麼有時候一群優秀的程序員，卻做不出優秀的產品？為什麼有的網頁遊戲，卻比3A大作賺錢？這就是對行業的理解，對受眾的把握。很多時候，程序員覺得這些和自己無關，不是知識。

但是，當在設計系統時，在權衡取捨時，我們做出的決定，往往是基於對需求的預測，而預測的準確與否，取決於對於行業的理解。很多想當然設計，和讓後繼者詬病不已的缺陷，多是源自行業知識的不足。

回到題目，一個跑了七八年的項目，自有其價值，不能簡單的稱之為垃圾。有更多的軟體，還沒有用戶就消失了。用現在的眼光，看十年前的技術，自然有很多問題，但有人用，就說明有需求。

好的做法不是重構，而是理解需求。

這類老的代碼，可能一半是補丁，一半是業務邏輯。不要在意補丁，多讀業務，讀懂了，就成了你的行業知識。別人不懂，你懂，你就是domain專家，下次競標這個行業的項目，就需要你的貢獻。自然而然，就可以參與立項和設計，進而經歷整個項目周期，完成接盤俠的蛻變。

就技術而言，開創項目時能學到的，也比中途接手要多的多。

感覺和領導提「重構」就是作死，即使懂技術的領導一聽這倆詞也是心裡咯噔一下。

你得說要避免加倆欄位「萬一出什麼差錯」，需要對系統做出怎樣的改動。把局部重構當成保證質量的必要條件，你們領導也不敢阻止你。

另外你們的這個系統明顯是處在售後階段，沒有任何經濟動力去做整體改進。如果你們的日常工作都是和這類系統打交道的話，說明公司已經沒有了新的系統項目。這要麼意味著公司經營方向發生了變化，要麼公司業務在走下坡路。

2017.01.06更新

一覺睡醒發現放了四個月有餘的答案迎來一波點贊，看過評論才知道被輪子哥點名了，先多謝輪子哥 @vczh 。

寫下這篇答案時，我剛離開公司不久（個人問題，並不是因為遇到和題主一樣的問題喲）。偶然看到這個問題實在是萬分感慨，所以隨手寫下自己的看法，原文中有不嚴謹的地方請各位見諒。

有幾處需要特別聲明的地方，避免有人會誤解我的意思：

所謂「垃圾代碼」是指當前需求最簡單最暴力的解法，不考慮代碼復用、解耦、優雅等等問題，並不是指惡意寫出無法閱讀的代碼，搞人工混淆的那一套。
我在原文中提及的做法，首先是我個人認為適合當時情況的做法，不一定值得大家直接效仿。其次，只有老代碼沒有規範可言且無人管理的情況下，我才會採取那些做法。老代碼中只要有談得上規範的東西，我基本都是遵守規範的。

有答主提到，還有很多更老的語言正在被維護，.net 1.0已經算很好的了。個人認為題主遇到的根本不是語言的問題，而是代碼管理、規範與領導想法的問題。國內許多小公司代碼管理之混亂，是沒有在小公司待過的人無法想像的。舉個例子，有些小公司是沒有產品經理和測試崗位的。對了，值得一提的是，題主領導也認為「 能熬一年就熬過一年 」。

說起來，這個問題很有意思，從不同角度來看問題，會得到完全不一樣的答案。

——————————————

以下原文：

負責任的做法有很多，但根據題主描述的情況，個人建議先放下程序員的責任心，寫些垃圾代碼，有必要時另尋出路。

在工作中處理過幾個這種項目。代碼各種複製粘貼，縮進完全沒有，到處是捨不得刪除的注釋代碼。經常某人替換了主程序中的組件，在項目文檔里完全不提及，需求更新時這就是個坑。

這種項目到手裡，我會將我看到的部分改為我的代碼風格，同時強記其中代碼邏輯。好在業務項目一般都是在自家代碼里複製出來的車軲轆代碼（至少我遇到的是這樣的），看多幾個項目就知道這群傢伙是什麼套路，再往裡插新的業務邏輯就不困難了。

如果遇到耦合度高、需要到處插入代碼的情況，可以做一個小工具。用樹狀圖顯示各類下各方法，然後批量選擇方法插入新代碼。

另外說一句，公司是沒什麼動力重構老項目的。

個人經驗：盡四成功力賴著做，按部就班不拖延不惱火不積極，能做成啥樣做成啥樣，項目栽了不賴你。不要逞能亂提新方案lead新方向。下一個項目好好乾翻個身。

我之前當過一次接盤俠，too young too simple，接了上任delay大半年的工作，接手時還有四個月這個項目就要發布，可上任早知道自己要升，毛都沒做丟下來。

更苦逼的是我當時都意識不到我接盤了，在上任的蒙蔽中以為項目就是這樣難的。

每天平均睡四個小時，沒有任何娛樂，一天吃一頓，家裡人生病了我沒照顧，各種遺憾+落了一身病，項目做完了…也取得了成績…

然後業績算了上任一半，原因是上任在交接時給予了我大量幫助。

操tm的

和其他人的建議相同，正在運行的系統，不要重構。系統正在客戶那邊運行，就明確說明一點問題，在目前的環境下，這些代碼運行良好。無非是舊了點，垃圾了點。

從接盤的角度來說，你已經很幸福了。我的幾個隊員接的可是pb5和pb9的代碼。估計很多人都沒聽說過這吧，sybase 公司出品，最新版本好像是pb13吧，嘿嘿。

照樣改代碼，照樣做。原因很簡單，就是這套系統在線上已經運行了10多年了，沒啥大問題，也沒有大的需求改動。當然也就不需要重構。

如果在內心中一定要上新代碼，想玩面向簡歷編程(捂臉)。建議你改大架構，移植代碼/啟用新模塊，新架構。

目前市面上的體檢系統，從大架構上來說，有cs和bs兩種。原先cs的，改成bs。原先bs的改成cs。當然這樣，需要給老闆一個合理的說法。

改動的方法，可以一個一個的改動。

比如先把職業病體檢系統，或者孕產體檢系統改掉。或者改動一些健康報告，健康評估，快遞寄送等檢後附屬系統，這些小模塊進行調整。

這樣做的好處，在於原先系統依然在運行，有bug，有需求也可以改動。但是全新語言，全新架構的產品也在研發。

題主也可以在簡歷上寫上漂亮一筆。

壞處，工作量很大啦。哈哈。

加油，題主。

最後無責任瞎猜下，杭州x景公司？

剛好派上用場：知乎專欄

如果題主想長期呆下去的話，那麼第一件事情應該是補測試。不然就早走早超生。

我之前也做過幾年醫院系統，看到這個問題忍不住進來吐槽幾句。

首先告訴題主，醫院的那幫人真不是一般的甲方啊，他們簡直是你大爺的大爺。每個科室都能提一堆需求，絕大部分還是沒吊用的需求。你還不能拒絕，拒絕就等著他們主任、信息科長、分管副院長，最後是你老闆來煩你。醫院系統的需求真特么的是進無止境，永無止境。所以，如果你公司的系統代碼辣雞，很難二次開發，那我奉勸你早走早超生。就像我一樣，離職之後感覺重獲新生，世界都變美好了。

至於你說的推倒重做，就算你對自己的代碼再有信心，再願意主動加班，儘快完成重做，你也很難找到一家醫院願意給你上線測試的。總之，從你公司到醫院，你都很難得到支持。所以，趁早死了重做的這條心。

邊開飛機邊換髮動機才是最牛逼的。

重新來誰不會啊，因為重新來基本都是在給別人挖坑。但是重構，並且能夠繼續保障業務開發，那才是真的有挑戰。

蝦米目前就是這個狀態，歡迎喜歡挑戰的人來！

早點走人吧

就讓它爛下去，放下程序員的尊嚴，放棄代碼執行的效率，採取各種無厘頭打補丁的辦法，用最短時間，應付完成各種需求。

具體問題具體分析，從你的描述中聽出3點：1、公司領導不支持推倒重來；2、不遠的將來甲方會更換新系統來替換你們現有系統；3、原來提出的需求一直拖著沒實現，甲方也沒有表達強烈的不滿。

這就很明顯，甲方和你們領導都默認了，你們這個系統的使命僅僅是在更換省里新系統之前湊乎用著，不出差錯不崩潰，能用一天算一天。

最大的可能性就是，從這個項目上掙到的錢太少了，公司根本沒動力繼續下功夫去進行完善。礙於合同的約束和甲方的面子，領導不得不安排你接手。而且這些問題甲方也是心知肚明的，否則影響業務流程的需求沒有響應，甲方早就打上門了。

每個人的時間都很寶貴，趕緊應付完去做更重要的事。

這種案例呢，說高大上一點，我們叫做「遺留系統改造問題」，你看，一下就上到了架構師的檔次了。

所以說年輕人多做擦屁股項目是極好的鍛煉，很快就能提升自己的設計能力。

PS：

說一個自己接過的最爛項目吧。不僅是接盤，還是二包。第一期的開發，客戶只要求對許多的數據進行錄入。一包的公司為了省事，竟然用縱表的設計，讓客戶自己填寫需要錄入那些欄位。所以，雖然錄入的數據量很大，但是人家這麼一做，第一期的開發就忽悠過去了。那麼第二期的開發，這麼多數據，客戶當然要看各種計算統計結果了。這下可好玩兒了，徹底爛攤子了吧？人家的負責人趕緊向公司打申請，包給我們公司，這樣出問題了也好推脫。好吧，這個嚴重的爛攤子，就徹底交給我了，而且還指派給了我一名年頭比我久的真·二貨程序員。不過由於攤子非常爛，我提出了設計方案以後，老闆還親自過會，討論我的方案。方案大致就是定時任務，在生產時間以後，讀取數據，統統算一遍，把統計結果放到新的表裡面。雖然不能實時看到最新的統計結果，但是根據客戶的實際情況，第二天能看到上一天的完整結果也是可以接受的了。

最後呢，因為用的這種妥協的方式，實際上客戶那邊也不是很滿意，但是因為不懂，對方公司再去忽悠溝通一陣，總算是交貨了。但是問題在哪呢？如果按客戶原來的需求，那麼這個就絕對不能採取縱表的設計，因為有些數據客戶其實是要看實時的動態變化和預警的。這個項目爛就爛在一開始沒有理清需求，又採取了不合理的設計。

你領導說的有道理，要是真讓你推到重寫，做integration估計會讓你跟痛苦，到時候會有客戶找你麻煩。

既然拿人錢財就替人消災吧。實在不爽就要求加薪唄。自己沒事多充電學習新技術。

你要明白，對於一家公司而言，手上現存的能運行能賣錢的「垃圾系統」比你只是嘴上說說一行代碼都看不到更不要提沒有經過用戶驗證的「先進系統」有價值得多了。

對於已經穩定的系統，正常的企業都是缺乏將它重構的動力的，在這個過程中花費的精力並不比開發一套新版本的系統小，甚至為了兼容某些老的設計，還會產生額外的風險。既然這樣，為什麼不直接開發新版本呢？

所以你要不然也撂挑子走人，要不然就慢慢重構自己負責的部分給自己的後續維護減少麻煩~

當然還有一種可能就是幾年後接你盤的人來知乎發同樣的牢騷。笑

領導不是說的很清楚么

再拖一年，你就拖一年唄

半年以前剛畢業，公司讓我去到某項目上，看了代碼感覺邏輯非常的，厄，magic。。。後來和客戶的需求一對比發現是個爛攤子。原來這個項目前期太濫，導致後期沒人敢接這個攤子，公司資源池裡就算有人，這些人寧可不幹活沒有績效也不做這個項目，結果就把我這個啥都不知道的應屆生拉上去死馬當活馬醫。。。

你猜現在咋樣了？現在我們項目追求的不是能交付多少是多少，而是完美交付。這個系統是客戶現在用的系統裡面最好的一個，鬼知道我半年都經歷了些什麼orz。。。

推倒重來，too young啊

那麼大一個系統，都做完了，你說重來就重來啊

顯然你領導是對的，現在的任務就是維護以及加一點小需求

而且你推倒重來，只不過是把前人的坑再踩一遍，可能還不如現有系統穩定

依你現在的情況，就繼續維護就可以了，實現新需求可以繼續複製粘貼

如果有短時間有更好的去處，或項目，離開這個坑不見得不行。

從你的描述上看你們居然沒有項目經理（專職或兼職）來溝通客戶，管控預算，調節進度和人員，也沒有技術負責人評估項目風險和軟體生命周期中所處的階段和問題。

那麼以題主你的水平，怎麼可能兼任項目經理，技術架構，以及代碼實現，測試，交付，這麼一系列的工作呢。

換個角度，如果你能基本勝任，找到辦法，是不是就可以做領導了。

本身就不應該全部重構！

(?????)

老闆說的沒錯，不應該完全重構

線上的代碼永遠是最好的代碼！

新功能可以用新代碼實現

甚至可以用新項目，通過通知方式實現

但是老代碼…請慎重

個人覺得，每次改動老代碼數量

不宜超過新代碼數量的20%