作為程序員,該如何去挽救一個失敗的項目?

一個很爛的項目，發現以下問題：

1. 一半的bean用spring管理，另一半的bean自己new或者用單例模式，spring的包掃描配錯了，但兩年時間一直沒人改過來

2.到處都是靜態類、靜態方法，沒法擴展

3.在低基數、低頻率的搜索上寫優化算法，算法和業務邏輯攪在一起，沒有分開為2個層面

4.業務配置文件過于復雜，過度設計，居然是事件模式解析

5.自己寫了個Dao，自己手動管理事務，到處拼sql，六七十個字段的表，每個操作都重復拼

6.4000行的大jsp、大類、800行的大方法、多達17個參數的方法，喜歡寫萬能函數

7.不寫注釋、不寫文檔

8.log4j和logbak混用，各占一半

9.混雜的代碼風格，花括號行尾、換行都有，縮進用tab、2空格、4空格、8空格，緊湊風格和松散風格都有

10.一些作者喜歡用反射調代碼，沒辦法用ide跟蹤

11.很多作者不用開源工具包，喜歡自己搞一套，有炫技嫌疑，實際上搞得很爛

12.分包分得一團糟，既想按照功能分，又想按照業務分，沒有把握好，稀里糊涂的

13.方法、變量命名詞不達意，經常在getXXX、isXXX的方法里改傳入參數，但又反回值，從命名就能看出作者詞匯量狹窄、思維局限

14.對spring、spring mvc了解和利用嚴重不夠，框架支持得很好的功能，非要自己寫

15.pom依賴關系一團糟，各種重復引包、重復依賴，httpclient竟然多達4個版本

16.大片的被注掉的代碼留在項目里，到處都是，許多廢棄的類和廢棄的配置文件沒有刪掉

17.每個作者都喜歡自己搞一套，缺乏共識，各自為戰，各種約定、各玩各的

18.該打日志的地方沒有打，導致一些工單成了無頭案，有些地方，又重復打日志，啰里啰嗦

19.到處都是HashMap，而不用java bean；1個HttpServletRequest調了五六層方法；自己手工拼json字符串；拼email的html body，不用模板

20.頁面還是jsp，jsp里寫了大量的業務邏輯，甚至通過httpclient去抓別的項目，抓回來內容嵌在當前頁面里

21.到處都是main方法，不用單元測試

22.代碼重復度很高，一段邏輯，到處復制粘貼

23.數據庫表設計很爛，導致不好查（比如用逗號分隔的串），較老得表甚至毫無注釋（生產環境）

24.整個團隊都沒有代碼質量追求，習慣了爛代碼

這個項目，是該公司交易系統的核心，每周大概4次發布，迭代速度很高。

往里面加邏輯異常困難、很容易出問題，開發和QA都心力交瘁，新邏輯都是hack進去的，會加重代碼腐爛。

若要重構，可能要同時維護2個版本，而且重構風險很大，一旦出事，將影響TL的前途。

如何擺脫這個困境？

1、程序員：“用心閣”

你應該得到足夠的職位或授權，建立共識，你的觀察和意見是否能夠得到領導和團隊成員的認可？如果沒有共識，或者無法建立共識，那么要么忍，要么滾。

2、程序員“fantini,碼農”

理智的做法： 辭職。

不理智的做法： 等到改不動再辭職。

3、程序員：“refuseBT”

見困難就跑的，還真不如代碼寫差點迎難而上的。作為一個新人，可以找時機提方案，在領導的允許范圍內主動承擔改進任務。你們領導也會一定程度為你提供資源和時間做這件事情。

首先這種事情必須從上往下推，甭說你TL了，TL上層的上層（我們公司是COO和CTO直接支持）都得支持才行。否則你想一個人干就是穩死。而且肯定是先把你干掉。

然后，優化至少得是照著一年去做計劃。最少最少。否則根本沒有任何可行性。而且之前一定要有非常詳細的策略推演，包括先做哪個模塊后做哪個模塊之類。不一定要立刻動手，但至少得驗證可行性，而且的有和你現存新項目的安排一起進行的可行性（這也是為什么必須要有高層支持）。

最后就是所有具體執行這件事情的人要給力。可行的方式是上層追蹤單元測試的覆蓋率等等參數，同時對員工提供提高代碼質量的培訓（SOLID和設計方法），然后把這個和員工的成績掛鉤。

當然了，最后的最后是你的員工得是有心思干這種事情的人。否則離職率太高的話這就是誰也救不了了。

幾點建議：

1.  策略一：

你要找公司的相關部門，如過程管理部，質量管理部，或項目管理辦公室，得到他們的支持，建立軟件開發過程，如：

需求文檔及評審

設計文檔及評審

代碼評審

單元測試

還可以找一些軟件系統來幫助這些過程的實施，如Bug跟蹤，代碼評審，代碼靜態分析。

2、策略二：

1．和leader溝通，需要他支持并承擔可能重構失敗帶來的責任

如果leader支持的話。

2.寫分析報告，指出存在的問題和風險，以及帶來的維護成本，匯報給公司，ppt會議最佳，讓領導知曉并觀察態度

如果公司覺得緊張的話。

3.給出重構計劃與好處、風險

如果公司支持的話，

4.開工，可以循序漸進地迭代，也可以大刀闊斧，最好先補測試用例，最好兩個版本分開

5.總結，告知本次重構的巨大工作量，以及為百年基業帶來的好處！

6.培訓，軟件開發規范，如果所在部門話語權不足，就內部培訓，邀請兄弟部門

總之，不要單以技術熱情來操作此事！！！

公司不認可，就說明代碼還沒有爛到他們覺得做手術的時候！！！就說明重構的市場價值不大！！！

公司不發話就別動！

如果公司的負責人有能力并且也有意愿來解決這些問題，建議好好跟著他干，做好執行，理解的要執行，不理解的也要執行。這是非常鍛煉自身能力，提高經驗值的事情。越亂越好，能夠把爛攤子理順，是能力的重要體現。不要因為眼前的這些問題而感到挫折，或者不爽，進而影響工作效率。盡量把事情做得更好。多大一個空格，把括號對齊也是改善。當然，跟爛攤子死扣也僅僅是修煉的一種方式。也可以有別的方式，辭職，換別的不同的公司也可以是種選擇。

最后轉個小故事：“在高盛期間，一次復雜的重組項目讓他真正學習到了東西。當時在國內投資界名噪一時的廣東粵海集團重組，高盛足足操作了兩年，中間涉及到100多家債權銀行，400多家公司，劉每天工作都到凌晨兩三點，兩年的項目感覺做了四年。但最終完成后，劉也對企業的管理、經營、執行幾乎所有流程都都全面了解，“做完這個項目，基本上再做任何項目都覺得容易了。

作為程序員，我們該如何去挽救一個失敗的項目？如何把難題變成獎品！

文章整理于“知乎”

本文固定鏈接:http://www.phpxs.com/post/4561

來自： http://www.jianshu.com/p/223ed3eecc7e